The Architect the System Cannot Live Without

The previous article in this series examined how organizational conditions help shape architecture. Organizations, however, do not act in the abstract. Decisions are made by people, knowledge resides with people, and the ability to keep an evolved system running despite its structural deficiencies can become concentrated in a very small number of individuals.

Long-lived systems therefore often have someone almost everybody knows. This person understands why an apparently harmless change in one place can break three unrelated areas. They remember edge cases that were never documented and historical decisions whose original rationale has long since disappeared. When a critical production incident occurs, they get the call; when a release stalls, they are asked to take a look. Where other developers may spend hours looking for the connection, this person can sometimes recognize the pattern within minutes.

Stakeholders have good reason to trust them: they have repeatedly demonstrated that they can solve problems. When the system is on fire, they save it. Yet this is exactly where a paradox can begin. The better a key individual becomes at compensating for poor structure, the less immediately the organization has to change that structure. The Big Ball of Mud creates a problem, the expert resolves it, and operations continue. From the organization’s point of view, this produces a perfectly understandable lesson: when things become critical, we need this person.

The next time something goes wrong, that person is involved earlier. Difficult tasks are routed to them, important decisions are checked with them, and other developers learn that asking them directly is often the fastest option. None of this makes the person less valuable. It makes them increasingly valuable. That is the paradox:

A key individual can simultaneously be one of the most valuable people in the system and one of its greatest risks.

The danger does not come from exceptional competence. Healthy organizations need people who know more than others and can solve problems others cannot. The risk emerges from the combination of exclusive knowledge, organizational dependency, insufficient independent review, decision authority, and a structure in which an increasing share of technical reality has to be interpreted through the same person.

The expert becomes indispensable because the system is bad. And the system can remain bad because the expert is indispensable.

The truck factor is only the obvious part

Software engineering has a familiar concept for concentrated technical knowledge: the bus factor, also known as the truck factor. In simplified terms, it asks how many key people would have to disappear from a project before continued development became seriously endangered. Software-engineering research also uses the truck factor as a measure of concentrated knowledge. Avelino et al., for example, investigated techniques for estimating that risk automatically from software repositories.

The obvious scenarios are familiar. A key individual resigns, is recruited away, changes roles internally, becomes unavailable for an extended period, or eventually retires. Only then does it become visible that while a team may have contained many developers, one particular part of the system was effectively understood by a single person. That continuity risk is real, but it is only the simpler half of the problem.

The truck factor describes what happens when the key individual is gone. The more interesting question is what their indispensability is already doing while they are still there.

Organizations change their behavior once they learn that a particular person can resolve critical situations especially reliably. That behavior can make the concentration of knowledge self-reinforcing.

The self-reinforcing knowledge loop

A knowledge monopoly does not have to begin deliberately. One developer may simply know one part of the system slightly better than their colleagues and therefore receive more of the difficult work in that area. Those assignments give them more experience, which increases the likelihood that they will also solve the next difficult problem faster. Their lead grows, colleagues and stakeholders notice, and still more critical work is routed to them. At the same time, other developers receive fewer opportunities to accumulate the same experience.

Over time, a small competence gap can become a structural knowledge asymmetry:

Knowledge → difficult tasks → additional experience → higher success rate → more trust → more critical tasks → even more exclusive knowledge.

At that point, the organization is no longer distributing competence; it is routing complexity to its expert. In the short term, this is rational. If a release is at risk, the work goes to the person most likely to resolve it quickly. If an important customer is waiting, that moment is rarely ideal for turning the incident into a multi-day learning exercise for someone less experienced. Yet the cumulative effect of many such locally rational decisions changes the team’s knowledge structure over time.

There is a second paradox as well. The person best positioned to distribute the knowledge is often the person with the least time to do so because their operational importance keeps pulling them back into urgent work. Every critical incident creates another perfectly reasonable argument for why knowledge transfer cannot happen right now. A knowledge monopoly therefore needs neither a plan nor malicious intent; it can simply grow.

The more often difficult problems are routed to the same person, the more strongly knowledge concentration can reinforce itself.

When rescue is more visible than prevention

A second asymmetry reinforces this loop. A production outage, a failed release, and an escalating incident are visible. So is the person who restores the system at 10 p.m. An architecture that prevented the same incident from occurring produces no comparable event. Nobody receives a message the next morning saying, “Congratulations, the bug that our clear module boundary prevented three years ago did not happen again last night.”

Operational rescue work is directly observable, whereas prevention often consists of events that never happen. This can create a reward problem without any organization consciously choosing to reward poor architecture.

The hero receives recognition for the rescue. Good structure rarely receives recognition for the rescue that never became necessary.

Fire prevention is less spectacular than firefighting. That does not make the recognition given to the expert undeserved. Someone who restores a critical production system late at night has delivered real value. The problem starts only when that performance continuously compensates for the structural conditions that keep making the performance necessary.

When other developers become dependent

The same mechanism can have another side effect for everyone else. A developer proposes a change, and the key individual responds, “That won’t work.” When asked why, the explanation runs through three historical edge cases, two implicit dependencies, an old workaround, and a component that has to be treated differently from everything else for reasons hardly anyone still remembers. Twenty minutes later it is clear that the change is more complicated than expected, and the pragmatic conclusion follows: “Give it to me. I’ll do it.”

The ticket is completed, but the knowledge is not transferred. The next similar problem follows the same pattern, until isolated incidents turn into a social rule: “Ask the expert,” “Only they should touch that,” or “I wouldn’t change anything there without them.” None of this requires the key individual to deliberately diminish other developers. Disempowerment can be a side effect of efficient problem solving.

When complex work is repeatedly routed to the same person, other developers lose learning opportunities. They accumulate less experience in critical areas, make fewer decisions there, and develop less technical autonomy. Over time, both sides can behave entirely rationally: the expert takes the task because they can solve it faster, while another developer hands it over because doing so appears to create less immediate project risk. In the long run, however, the same competence gap that justified the decision is reproduced and becomes the reason for making it again next time.

The system may formally have twenty developers. Some parts of it may still effectively have only one.

When knowledge becomes expert power

Knowledge concentration changes more than the technical division of labor; it also changes social power. French and Raven described several bases of social power as early as 1959. One of them is expert power: influence that arises because others attribute special competence and knowledge to a person. Later developments of the model distinguish, among other forms, expert power, referent power, and informational power.

Expert power is not inherently problematic. Someone who knows more about a technical subject should usually carry more weight in a decision than someone who does not understand it; organizations would be foolish to ignore experience and competence. A person who repeatedly solves complex problems therefore earns trust. Stakeholders and managers know them, and perhaps support, operations, or important customers do as well. When that person says in a meeting that a change is risky, the statement rightly carries weight.

The situation changes when “They know the system best” slowly becomes “If they say it cannot be done, then it cannot be done.” That is a qualitative shift. Issac et al. explicitly investigated how expert power and referent power relate to knowledge sharing and knowledge hiding. Their study of employees in knowledge-intensive environments found a more nuanced picture than a simple equation between power and withholding knowledge. One relevant factor was how respondents expected sharing unique knowledge to change their personal power. Expected losses of power were associated with a lower intention to share and greater knowledge hiding. The point is therefore not that “power causes hiding,” but that what people expect to gain or lose through knowledge transfer can matter.

For architecture, this creates an important distinction. Expertise is valuable, and expert power can be both legitimate and useful. The problem begins when professional authority can no longer be constrained by independent technical scrutiny.

The more indispensable a person becomes, the more dangerous it is to constrain their decisions through trust alone rather than through verifiable structures.

Three stages of dependency

The progression can be described as a three-stage analytical model. These stages are not an established scientific taxonomy; they are a way of separating different qualities of technical dependency.

1. Knowledge concentration

At the first stage, the situation is: “Only this person knows how it works.” This is essentially the classic bus-factor problem. The knowledge exists but is poorly distributed, and the organization loses an important part of its ability to act if that person becomes unavailable.

2. Operational dependency

At the second stage, concentrated knowledge becomes operational dependency: “Without this person, we cannot get the release or incident resolved.” The person becomes both a bottleneck and the rescuer of critical situations. Other people may understand the area at a high level, but the same individual is still required for the cases that truly matter.

3. Epistemic dependency

The third stage is subtler: “If this person says something cannot be done, the organization has almost no independent way to test that statement.” At this point, the dependency is no longer only on labor or technical knowledge. It extends to how one person interprets technical reality.

The organization is no longer merely dependent on one person’s work. It is dependent on that person’s interpretation of reality.

Concentrated knowledge can develop into operational and eventually epistemic dependency.

When the explanation itself can no longer be checked

An anonymized experience from a long-lived frontend system illustrates how far this dependency can reach. Over the years, the distance between the application and the evolution of its framework had grown. An upgrade from Angular 17 to Angular 19 was still considered technically possible, but the expected effort had already reached roughly three months. With the next major release, the assessment became more severe: moving the concrete system to Angular 20 was considered practically unrealistic or no longer feasible.

In one discussion, the responsible architect summarized the situation approximately as follows:

“The people at Google really messed this up.”

Whether that diagnosis was technically right or wrong is not the decisive issue here. Large framework teams make bad decisions as well, and Google’s size or reputation would be no evidence that one architect must automatically be mistaken. What mattered more was that the stakeholders in the room had almost no realistic way to evaluate the explanation independently.

Several hypotheses should have been competing. Angular might indeed have introduced a problematic breaking change. The application might have depended on an API whose behavior had changed. Angular mechanisms might have been bypassed for years, or custom abstractions might have blocked the intended upgrade path. The actual effort could also have resulted from a combination of framework changes and historically accumulated application architecture. “Google messed this up” was therefore one possible explanation, but it remained exactly that: a hypothesis.

In a technically healthy environment, such a hypothesis can be tested against alternatives. Teams can identify concrete breaking changes, construct minimal reproductions, compare the application’s APIs and patterns with documented framework mechanisms, or bring in external expertise. The danger is therefore not that an expert has a strong opinion.

The problem begins when that opinion becomes difficult to falsify because of the person’s position.

At that point, a knowledge monopoly has acquired a second meaning. It no longer means only that one person knows the answers; it can mean that the organization lacks an independent way to assess those answers. Technical authority then ceases to be merely a consequence of greater experience. It becomes part of the infrastructure through which the organization interprets reality.

Expertise and transformation competence are not the same thing

Highly capable key individuals often possess skills that are genuinely exceptional in a Big Ball of Mud. They have operational knowledge of real production behavior, domain knowledge of business rules and historical exceptions, and often deep navigation knowledge of implicit dependencies, workarounds, and hidden coupling. They may also be highly skilled architects.

None of those capabilities automatically implies transformation competence. Mastering an existing system and fundamentally reshaping that system are different tasks. Transformation may require challenging familiar assumptions, reevaluating one’s own earlier architecture decisions, discarding parts of a mental model developed over many years, and deliberately creating redundancy in knowledge and distributed decision-making capacity.

The person who understands a system exceptionally well is not automatically the person best positioned to judge how radically that system should change.

This is not an argument against expertise; it is a distinction between different kinds of expertise. In a Big Ball of Mud, navigation knowledge can have enormous economic value. Someone who knows that an apparently independent change requires Service A to be started first, State B to be synchronized next, and Cache C to be invalidated afterward prevents real production failures. At the same time, the organization should ask why that knowledge is necessary in the first place.

Navigation knowledge about a Big Ball of Mud can be extremely valuable even though the organization should be trying to reduce the need for exactly that knowledge.

A cleaner system does not make domain knowledge, experience, or excellent architects less valuable. It does, however, reduce the value of exclusive knowledge whose main purpose is navigating structural chaos. This is where the analysis becomes uncomfortable.

Technical change also changes personal resources

If knowledge can create power and organizational importance, modernization is not exclusively a technical change. Exclusive knowledge can be connected with status, recognition, autonomy, access to decision-makers, and organizational centrality. None of that has to be designed. A person can acquire such a position over many years simply by solving difficult problems reliably.

If knowledge is then distributed, standards are restored, and other developers become able to change the same areas independently, that position may also change. What counts as risk reduction for the organization may amount to a loss of exclusive importance for the key individual. This is not yet a moral judgment; it is a potential conflict of interest.

People have self-interests. Professional identity, recognition, status, autonomy, and job security are real parts of working life. It would be naive to model technical organizations as though those interests did not exist. The situation becomes particularly relevant when the same person whose role might change through a transformation also has substantial influence over whether that transformation is considered technically necessary in the first place.

The person whose position may be affected by a change may simultaneously have substantial influence over whether that change appears necessary at all.

Such a conflict of interest is not proof of misconduct, but neither is it irrelevant. That is precisely why an organization should not build its architecture on the assumption that people have no self-interest, even though professional behavior can and should be expected.

An organization can expect professional behavior. It should not build its architecture on the assumption that people have no self-interest.

Exclusive knowledge can create not only technical value but also status, influence, and decision power.

Knowledge can also mean security

Job security is an especially sensitive part of this discussion. The easy accusation would be that someone deliberately withholds knowledge in order to make themselves harder to replace. Without evidence, that claim would be irresponsible. Research does, however, provide reasons not to exclude job insecurity from the analysis altogether.

Jeong, Kim, and Lee studied the relationship between perceived job insecurity, psychological safety, and knowledge hiding in a three-wave study of 365 employees in 2023. In their model, greater job insecurity was associated with lower psychological safety, which in turn was related to more knowledge hiding. They interpret the mechanism partly through Conservation of Resources theory.

This does not show that people create knowledge monopolies in order to protect themselves from dismissal, nor does it justify diagnosing the motivation of any particular architect. It does show why the opposite assumption would also be too strong: that job security could never matter to knowledge exchange.

Exclusive knowledge has more than technical value. In insecure contexts, it can also be perceived as a personal resource.

This matters because modernization often takes place precisely when roles, responsibilities, and existing competence profiles are already being reconsidered. If a key individual is simultaneously expected to distribute exclusive knowledge and thereby reduce the uniqueness of their former position, technical and personal interests can intersect. The extent and form of that intersection can only be judged in a concrete case; pretending it cannot happen should not be a requirement for polite technical discussion.

Status is more precise than “ego”

Technical discussions often reduce this kind of behavior to one word: ego. More precise concepts are expert status, recognition, reputation, professional identity, and self-concept. Someone who has spent ten years being known as the person who understands a critical system may have built a significant part of their professional identity around that competence. That is not irrational. Work is more than the execution of interchangeable tasks; people develop role identities, reputations, and expectations about what others value them for.

Moser explicitly frames knowledge exchange for experts as a social dilemma. Sharing valuable knowledge benefits the group, while an individual expert may give up a competitive advantage by doing so. At the same time, two experiments found that experts contributed more when their expert status was recognized. Status therefore does not simply prevent knowledge sharing; recognition can actively support it.

That is an important counterweight to an overly simple story about power. An expert does not have to fit into a binary category of “cooperative” or “power-seeking.” People can share knowledge while still caring that their expertise remains visible and recognized. Modernization can alter that balance. If a technical reassessment implicitly says that many rules, workarounds, and special paths previously defended or protected will no longer be needed, the change affects more than code.

A technical reassessment can also become a reassessment of what previous professional authority was built on.

Professionals can deal with that. Organizations should not assume that status and identity therefore cease to matter.

Not every knowledge monopoly is knowledge hiding

A conceptual distinction is essential here. In organizational research, knowledge hiding is not a synonym for poorly distributed knowledge. Connelly, Zweig, Webster, and Trougakos established it as a distinct construct and separated it from concepts such as knowledge sharing and knowledge hoarding. Knowledge hiding refers to the intentional attempt to withhold or conceal knowledge another person has requested, with forms including evasive hiding, rationalized hiding, and playing dumb.

That distinction matters for software architecture. A system can depend heavily on one person even if that person has never deliberately withheld knowledge. Knowledge concentration first describes a state. Tacit knowledge can arise because experience is difficult to document completely. Missing documentation or insufficient learning opportunities can emerge through time pressure and years of neglect. Knowledge hoarding, and especially knowledge hiding, introduce intentionality much more strongly.

Research on knowledge hiding is therefore not evidence that every key architect deliberately keeps colleagues uninformed. Its relevance is that it studies intentional withholding of knowledge as a real organizational behavior. A large meta-analysis by Arain et al. synthesized 104 studies comprising 31,822 employees and examined a broad network of individual, relational, and organizational antecedents and outcomes. The appropriate conclusion is therefore neither “a knowledge monopoly is always intentional” nor “intent never matters.” Both positions would be convenient, and both would be wrong.

When knowledge is experienced as “mine”

Another research stream examines psychological ownership. People can experience knowledge, tasks, or areas of responsibility as something that belongs to them. Such ownership is not inherently negative. Responsibility, identification, and personal commitment can be extremely valuable for a system. Problems can arise when responsibility turns into a claim of possession and the language shifts toward “my area,” “my services,” “my architecture,” or “nobody changes that without talking to me first.”

The distinction again matters: psychological ownership is not identical to territoriality; territorial behavior is one possible response to it. Huo et al. studied this relationship in a two-wave sample of 417 people from Chinese research and development teams. In their model, territoriality mediated the relationship between psychological ownership and knowledge hiding. Tian et al. examined knowledge-based psychological ownership more specifically with 310 knowledge workers. In their three-wave study, expected loss of knowledge power mediated the relationship with knowledge hiding, while emotional intelligence weakened the indirect effect.

These findings should not be overgeneralized. They come from specific samples studying organizational knowledge work, not specifically software architects in large European software programs. They are nevertheless relevant to the conceptual question because they show that knowledge need not be experienced as neutral information alone. It can become psychologically connected with possession, power, and expected loss.

The boundary between responsibility and a claim of ownership matters organizationally.

A good architect should take responsibility. An organization should still pay attention when responsibility effectively means that an area can no longer be changed, understood, or evaluated independently without one person’s approval.

Power is not a dirty word here

It would be tempting to replace power with softer terms such as “standing,” “influence,” or “seniority.” The established organizational concept of expert power is more precise: this is about power. A person has power when their judgment influences which technical explanation is accepted, which change may proceed, which risk is communicated to stakeholders, or which alternative is considered realistic in the first place.

That power can be legitimate, useful, and grounded in real competence. It does not stop being power simply because competence is its source.

Whoever can shape how a problem is explained also influences which solutions can be imagined.

This becomes particularly important when organizational counterweights are weak. A formal architecture board, a second senior engineer, or a review process offers little independent scrutiny if everyone still has to ask the same key individual to interpret the decisive technical details. A control structure may exist on the organization chart while failing to exist epistemically.

Unconscious stabilization

Up to this point, the mechanism still requires no deliberate obstruction. A key individual may genuinely believe they are protecting the company, and they may have excellent reasons for doing so. They know real production problems, remember the cost of earlier mistakes, and have seen apparently harmless changes trigger unexpected side effects. Caution can therefore be technically justified.

The difficulty is that this person’s mental model has evolved together with the existing system. Rules, exceptions, workarounds, and historical architecture decisions form a coherent whole within that model. Over time, it can become difficult to distinguish between a rule that is genuinely unavoidable for domain or technical reasons and one that only appears necessary because the current architecture created the constraint.

A particular sequence “has” to be followed, a component “cannot” be replaced, a framework “isn’t suitable,” or a standard solution “doesn’t work here.” Any of these statements may be true. In a highly evolved system, however, “necessary” can sometimes mean only “necessary under the assumptions of the system as it exists today.”

The person who understands that system best therefore does not automatically have the most neutral perspective on its fundamental assumptions. This is neither a cognitive defect nor a character flaw; it can be a direct consequence of deep experience with an existing model. A key individual can therefore stabilize the status quo while sincerely believing they are reducing risk.

Deliberate stabilization exists as well

The analysis cannot stop there, because people have agency. A person can recognize that a change will reduce their influence, make other developers more independent, make parts of their exclusive navigation knowledge less important, or call earlier technical decisions into question. They can respond to those consequences.

Possible behaviors include continually raising the evidentiary bar for change, emphasizing the risks of alternatives disproportionately, dismissing competing approaches without equivalent evaluation, centralizing reviews and approvals, or sharing knowledge selectively. Even the statement that a standard approach is “not possible in our system” can become an informal veto if nobody else can independently test the claim.

None of this means that such behavior is typical of key individuals, nor does a rejected modernization proposal demonstrate a desire to preserve power. The reverse position, however, would be equally unrealistic:

Ignoring the possibility of deliberate power preservation out of politeness would be just as problematic as attributing it to every key individual.

Avoiding blame therefore must not become an excuse for removing human interests from the model.

Experts are not passive objects of their organizations

Research by Peter Kalum Schou and Torstein Nesheim provides an interesting perspective here. In a qualitative study, they examined expert engineers in a large energy company during an organizational change. The company centralized tasks and introduced digital control mechanisms, reducing some of the experts’ previous autonomy and formal control.

The researchers observed that the experts did not respond passively. They developed practices that allowed them to regain parts of their earlier control, including strategic compliance combined with workarounds, the use of legacy structures, and informal restoration of expert control. Schou and Nesheim group these practices under the concept of stealth work.

The study must be transferred cautiously. It concerns expert engineers in a particular company and a specific change process; it does not show that software architects generally sabotage reforms behind the scenes. Its relevance lies elsewhere: experts are not merely objects of organizational structures. They have agency, can respond to changes in status, autonomy, and control, and can themselves influence the emerging order.

A key individual is not only shaped by organizational structures. They can actively shape those structures in return.

That makes the explanation “the organization created the problem” incomplete. Organizational conditions can encourage knowledge concentration, time pressure can reinforce it, and legacy structures can preserve it. Eventually, however, concrete people still make concrete decisions.

High competence does not eliminate the need for scrutiny

The very fact that key individuals are often exceptionally capable creates another risk. A junior developer can make a wrong technical judgment and, in a healthy team, have that judgment challenged during review. A widely respected architect can make the same kind of error, but their conclusion may reach several teams, affect budgets, or eliminate a technical option before it is even prototyped.

The difference is not intelligence; it is reach. The greater a person’s decision power, the greater the possible reach of an incorrect decision. The same principle applies to managers, product owners, security specialists, and other influential roles.

High competence reduces the likelihood of some mistakes. It does not make institutional counterchecks unnecessary.

Trust must therefore never become a substitute for falsifiability. A good expert should be able to make strong arguments; a good organization should remain capable of testing them.

A provocative consulting rule

An anecdote from consulting work in another business unit captures the problem in deliberately extreme form. The reported rule was that when critical knowledge had become completely concentrated in a single person, consultants would sometimes recommend separating from that person.

As a general recommendation, that would be dangerous. An organization already structurally dependent on one person can destabilize itself severely by removing them abruptly. Removing the one person who still understands the system does not remove the dependency; in the worst case, it only removes the knowledge.

The provocation is still useful because it exposes two questions organizations prefer not to ask:

What remains of the organization’s technical ability to act if this person is unavailable tomorrow?

Does the organization still have enough incentive to reduce the dependency while that person reliably absorbs every critical situation?

The appropriate conclusion is therefore not to remove the expert but to remove the monopoly. Exceptional expertise should remain in the organization; what must not remain is a state in which only that expertise makes the organization capable of acting. How to achieve that belongs in the later article on finding a way out of a Big Ball of Mud.

The key-person paradox

The individual mechanisms can now be connected. A Big Ball of Mud is difficult to understand, which makes navigation knowledge valuable. The person with the most navigation knowledge solves difficult problems more successfully and therefore receives more of them. Their rescues are visible and increase trust among colleagues and stakeholders; that trust increases their expert power, and more critical decisions flow through them. Other developers receive fewer opportunities to accumulate comparable experience, which concentrates knowledge still further.

Indispensability can then become associated with status, autonomy, organizational centrality, and, under some conditions, a sense of personal security. A modernization effort that makes the system easier to understand would simultaneously reduce the exclusivity of that knowledge. A change that reduces organizational risk can therefore alter resources that matter personally to the key individual. They may consider the change technically wrong because of deep experience with the system, may unconsciously stabilize the existing model, or in some cases may deliberately resist it.

If the change does not happen, the system remains difficult to understand. Navigation knowledge therefore remains valuable, and the loop can begin again. As an analytical model, the mechanism can be summarized as follows:

Big Ball of Mud → difficult-to-understand system → exclusive expert knowledge → operational rescue → trust and expert power → more centralized decisions → less distributed knowledge → stronger dependency → harder change → Big Ball of Mud remains.

This is not a universal law. It is a possible self-reinforcing mechanism that becomes particularly plausible in long-lived Big Balls of Mud.

The expert can become indispensable because the system is bad, while that very indispensability can help the structural causes survive longer.

Avoiding blame does not remove responsibility

It would be easy to find a villain for this loop. It would be equally easy to make every individual choice disappear behind the label “systemic problem.” Neither approach is useful.

The organization is responsible for recognizing knowledge monopolies, avoiding the permanent institutionalization of dependency, and keeping technical claims independently testable. It must also create conditions in which knowledge transfer is not indefinitely displaced by the next incident. The key individual still has agency as well. They can share or withhold knowledge, build up other developers or continually pull work back toward themselves, explain decisions transparently or rely on authority, and welcome or dismiss disagreement. They can shape their role so that expertise enables other people, or so that the same expertise remains a permanent prerequisite for everyone else’s ability to act.

These decisions do not all have the same motivation, and motivation is often impossible to infer reliably from the outside. Responsibility does not disappear for that reason.

Avoiding blame does not mean treating individual behavior as irrelevant.

Organizational causes help explain how a context for action emerged. They do not determine every action taken within it. People have agency.

What the research shows — and what it does not

Because this subject can become personal very quickly, the line between empirical evidence and interpretation matters. Research shows that knowledge hiding is a real and extensively studied organizational phenomenon. Connelly et al. established it as a distinct intentional construct, and later meta-analyses document a substantial empirical literature on its antecedents and consequences. Individual studies connect psychological ownership and territoriality with knowledge hiding and suggest that expected loss of knowledge power can matter. Research on expert status and expert power also shows why status and power cannot simply be equated with withholding knowledge: recognition of expert status can encourage sharing, while expected power losses can make sharing more difficult. Studies of job insecurity provide evidence that perceived insecurity can relate to knowledge hiding through psychological mechanisms. Finally, Schou and Nesheim show in one qualitative case that experts can actively respond to losses of autonomy, status, and control and develop informal practices to regain parts of that control.

The research does not show that every key architect deliberately withholds knowledge, that every expert defends their power, or that job security explains a particular architecture decision. Nor does it show that every strong technical objection reflects threatened status or professional identity, or that organizations should distrust their best experts simply because those experts have influence. Personal experiences can open the question and illustrate mechanisms; generalization has to be carried by research. That distinction is precisely what makes it possible to discuss power, status, security, territoriality, and deliberate knowledge hiding without diagnosing specific people without evidence.

Organizations need experts, not infallibility

Organizations should have exceptional experts: people who know more than others, understand historical context, solve difficult problems, and bring exactly the right experience into a crisis. The risk does not begin with competence. It begins with exclusivity.

When only one person understands essential parts of a system, can resolve its most critical incidents, must effectively approve important changes, and is simultaneously the only person considered credible enough to judge whether technical claims about the system are true, the organization has become structurally dependent. That dependency need not have been created deliberately or maintained consciously. It can nevertheless interact with personal interests because knowledge can create status, influence, autonomy, and, under some conditions, a sense of security. A change that makes the system healthier for the organization can therefore change the significance of the person who previously made it survivable.

That does not make the person a villain. It makes the situation a conflict of interest that a professional organization should not ignore.

The truck factor describes what happens if the key individual is gone tomorrow. The knowledge monopoly is already a problem while they are still there.

More dangerous than operational dependency is epistemic dependency because it affects not only the ability to perform work but also the ability to evaluate technical claims independently:

The most dangerous form of a knowledge monopoly is not that only one person can repair the system. It is the point at which only that person can explain what is technically true.

That is why an apparent strength can sometimes be a warning sign: the person who can always help, knows every exception, is called in every crisis, and without whom nothing seems to work. The risk is not exceptional knowledge itself; it is that the organization can gradually lose the ability to act without that one body of knowledge.

A key individual can simultaneously be one of the most valuable people in the system and one of its greatest risks.

A healthy organization has experts. A fragile system needs heroes.

The direction of a later remediation strategy is already visible without developing it here: the expert does not have to disappear. The monopoly does.

Sources and further research

• Avelino, G., Passos, L., Hora, A. & Valente, M. T. (2016): A Novel Approach for Estimating Truck Factors. 24th IEEE International Conference on Program Comprehension. DOI 10.1109/ICPC.2016.7503718.
• Connelly, C. E., Zweig, D., Webster, J. & Trougakos, J. P. (2012): Knowledge hiding in organizations. Journal of Organizational Behavior, 33(1), 64–88. DOI 10.1002/job.737.
• French, J. R. P. Jr. & Raven, B. H. (1959): The Bases of Social Power. In D. Cartwright (ed.), Studies in Social Power. Institute for Social Research, University of Michigan. For a later development of the model, see Raven (1993): DOI 10.1111/j.1540-4560.1993.tb01191.x.
• Issac, A. C., Bednall, T. C., Baral, R., Magliocca, P. & Dhir, A. (2022): The effects of expert power and referent power on knowledge sharing and knowledge hiding. Journal of Knowledge Management, 27(2), 383–403. DOI 10.1108/JKM-10-2021-0750.
• Moser, K. S. (2017): The Influence of Feedback and Expert Status in Knowledge Sharing Dilemmas. Applied Psychology, 66(4), 674–709. DOI 10.1111/apps.12105.
• Huo, W., Cai, Z., Luo, J., Men, C. & Jia, R. (2016): Antecedents and intervention mechanisms: a multi-level study of R&D team’s knowledge hiding behavior. Journal of Knowledge Management, 20(5), 880–897. DOI 10.1108/JKM-11-2015-0451.
• Tian, Y., Mao, L., Zhou, M. & Cao, Q. (2021): Knowledge-based psychological ownership and knowledge hiding: The roles of loss of knowledge power and emotional intelligence. Social Behavior and Personality, 49(8), e10530. DOI 10.2224/sbp.10530.
• Jeong, J., Kim, B.-J. & Lee, J. (2023): The effect of job insecurity on knowledge hiding behavior: The mediation of psychological safety and the moderation of servant leadership. Frontiers in Public Health, 11, 1108881. DOI 10.3389/fpubh.2023.1108881.
• Arain, G. A., Bhatti, Z. A., Hameed, I., Khan, A. K. & Rudolph, C. W. (2024): A meta-analysis of the nomological network of knowledge hiding in organizations. Personnel Psychology, 77(2), 651–682. DOI 10.1111/peps.12562.
• Schou, P. K. & Nesheim, T. (2024): What We Do in the Shadows: How expert workers reclaim control in digitalized and centralized organizations through ‘stealth work’. Organization Studies, 45(5), 719–744. DOI 10.1177/01708406241233175.