What a Big Ball of Mud Does to People

A Big Ball of Mud can be described in technical terms. We can count dependencies, visualize cycles, look for global state, examine change radii, and trace why an apparently local modification causes side effects somewhere entirely different. For people who spend years working on such a system, however, it is more than a technical structure. It is their daily work environment.

Developers do not merely learn APIs, frameworks, and business rules. They also learn which changes are risky, which areas nobody fully understands, whom to ask before touching a particular part, which problems are better worked around, and which rules exist nowhere in the documentation but still have to be obeyed. That shifts the perspective from how a Big Ball of Mud changes software to a different question:

What does a software environment that remains difficult to understand and difficult to change do to the people who work in it for years?

People do not spend years in an environment like this without adapting to it. That is neither inherently good nor bad. Adaptation is a normal response to working conditions, and different people bring different experiences, skills, expectations, and professional values. The same technical environment can therefore be experienced in very different ways.

This is where a second layer of the Big Ball of Mud appears. Eventually it no longer consists only of technical structures. Social norms emerge around it — norms about how people work inside it. This article uses three idealized response patterns to explore that dynamic: the navigator, the adapted or resigned developer, and the structure-oriented change agent. These are not personality types. The same person may exhibit several of these patterns over the course of a career or move from one to another.

Occupational psychology does not study Big-Ball-of-Mud systems as a distinct category. General findings on burnout, Person–Environment Fit, Employee Voice, or Organizational Socialization therefore cannot simply be presented as direct findings about poor software architecture. Research on burnout in software engineering itself has become more substantial; a systematic mapping study by Tulili, Capiluppi, and Rastogi identified 92 relevant studies. Even so, that does not establish a specific causal mechanism in which a Big Ball of Mud leads to burnout.

The more defensible scientific question is therefore: Which working conditions can emerge in long-lived Big-Ball-of-Mud systems — and what does occupational and organizational psychology know about comparable conditions?

Three Possible Responses to the Same Environment

A system that is difficult to understand does not create the same work environment for everyone. Person–Environment Fit research has examined for decades how well a person’s characteristics, needs, and values align with their work environment. The meta-analysis by Kristof-Brown, Zimmerman, and Johnson combined 172 studies with 836 effect sizes and examined several forms of fit as well as their relationships with attitudes, performance, withdrawal behavior, strain, and retention.

For a Big Ball of Mud, one distinction is especially useful: whether a person functions well in an environment is not the same question as whether that environment is well designed technically. The following three patterns should therefore not be read as three kinds of developers, but as three possible responses to the same work environment.

The same technical environment can be experienced and answered in very different ways.

The Navigator

Some people can work remarkably successfully in a poorly structured system. After a few years, they may have built a detailed mental model, recognize failure patterns that outsiders can barely classify, and know not only the official structure but also the historical exceptions and implicit coupling. They know which supposedly independent components actually interact, which changes tend to produce side effects, and which person to ask about a particular problem.

In an environment where explicit boundaries provide little orientation, the ability to recognize implicit relationships and manage uncertainty pragmatically becomes valuable. The navigator’s capabilities therefore fit comparatively well with a work environment in which navigation has become more important than explicit structure. That does not mean the person “likes chaos,” nor does it imply that the technical structure is healthy.

A person can be a good fit for a bad structure.

That distinction matters. A complicated incident may be an engaging problem for the navigator, while the same incident is mainly another obstacle for someone who has been unable to change its underlying causes for years. Because the navigator’s day-to-day work functions, there may also be relatively little subjective pressure for fundamental change. From that perspective, a major restructuring can initially mean replacing a highly effective mental model built over years with an unfamiliar one.

Over time, a navigator may become a key person. That is not inevitable and was discussed in more detail in the previous article. For the purposes of this article, the important point is that a Big Ball of Mud can make certain capabilities extraordinarily valuable — capabilities that would be far less exclusive in a system whose structure was more explicit.

The Adapted or Resigned Developer

A second response pattern can look from the outside like disinterest in architecture or resistance to change. The person does not have to like the state of the system. They may once have proposed refactorings, supported modernization initiatives, or tried to clarify responsibilities. Over time, however, they may have learned that major change efforts are costly and rarely achieve their original goals.

What changes is not necessarily their technical assessment, but their strategy. Instead of addressing underlying causes, they rely more heavily on known and comparatively safe paths. They use existing workarounds, avoid certain components, reduce the scope of risky changes, and invest less energy in initiatives they now consider unlikely to succeed. Statements such as “We already tried that,” “Just do the ticket,” or “Better not touch that area” can express cynicism in this context, but they can also summarize accumulated experience.

Adaptation can range from healthy pragmatism to deep resignation.

This distinction matters because a software organization cannot restructure the entire system with every change. Experienced developers have to assess risk and decide when a workaround is economically sensible. Pragmatism is therefore not a symptom of a Big Ball of Mud. The more interesting point is what happens when people stop expecting structural change efforts to have meaningful effects at all.

Research on Cynicism About Organizational Change offers a useful concept here. Reichers, Wanous, and Austin described change cynicism in part as pessimism about the likelihood of future change success and identified a history of change programs that were not consistently successful as one context in which such cynicism can develop. Later work in the same research stream supports the idea that this cynicism need not be purely dispositional; it can also be learned from experience with change.

Resignation can look like resistance to change from the outside. It can also be the result of repeatedly unsuccessful attempts to change things.

In that case, “We already tried that” may contain more organizational history than resistance.

The Structure-Oriented Change Agent

The third pattern initially resembles what architecture textbooks often expect. A person may come from systems in which responsibilities were relatively clear, changes were mostly local, architecture rules actually constrained the design, and technical problems could at least in principle be addressed at their causes. In a Big Ball of Mud, this person therefore tries to create structure: removing cycles, adding tests, questioning dependencies, clarifying ownership, narrowing public interfaces, and searching for meaningful domain boundaries.

Many of these diagnoses can be technically correct. But a long-lived Big Ball of Mud is no longer merely a code problem. A cycle may persist because two teams have overlapping responsibilities. A poor API may reflect an unresolved business process. A global service may bridge several historical organizational boundaries. A sensible migration may collide simultaneously with delivery commitments, limited authority, key-person dependencies, outdated infrastructure, and previous modernization efforts that failed.

The structure-oriented developer is therefore not only pushing against dependencies in code. They are pushing against a network of technical and organizational constraints whose alteration may require far more decision-making authority than their role provides. This is where a particular form of misfit can emerge: the person may see the problem clearly, feel responsible for it, and know technically plausible alternatives, while repeatedly experiencing that their actual control is insufficient to change the underlying causes.

A structure-oriented developer may be especially strained when they can see the problem clearly, feel responsible for it, and repeatedly experience that their influence is insufficient to change its causes.

This does not mean structure-oriented people inevitably suffer more. It is a mechanism hypothesis. It is, however, compatible with occupational psychology, because both low job control and misfit between a person and their work environment are well-established areas of research on work strain. Park and colleagues’ meta-analysis examined 71 independent samples from 66 studies with 48,528 participants and found substantial relationships between job control and dimensions of burnout. The broader Person–Environment Fit literature also links poorer fit with strain and withdrawal-related outcomes.

Exhaustion Is Not Only About Working Hours

Burnout invites a dangerous simplification: if someone is not constantly working overtime, they supposedly cannot burn out. Research presents a much more complex picture. Maslach and Leiter describe burnout in terms of exhaustion, cynicism or psychological distancing, and reduced professional efficacy. Their Areas of Worklife model identifies six areas in which the relationship between a person and their work matters: Workload, Control, Reward, Community, Fairness, and Values. The Job Demands–Resources Model, in turn, focuses on the relationship between the demands of a job and the resources available to meet those demands.

Workload matters in these models, but it is only part of the picture. A systematic review and meta-analysis by Aronsson and colleagues focused on prospective or comparable studies and found moderately strong evidence that greater job control was associated with lower subsequent emotional exhaustion; low workplace support showed a corresponding relationship. The authors reported more limited evidence for additional factors including high demands, high workload, low reward, job insecurity, and workplace justice. Alarcon’s meta-analysis reaches a similar overall pattern from a different theoretical perspective: higher demands, fewer resources, and less favorable work-related attitudes are associated with burnout.

Software development is not fundamentally exempt from these dynamics. Singh, Suar, and Leiter studied 372 software developers and found relationships between burnout and factors including role ambiguity, role conflict, schedule pressure, irregular shifts, and lack of group cooperation. The systematic mapping study by Tulili, Capiluppi, and Rastogi summarizes a much broader software-engineering literature and identifies job demands, overload, and tension at work among recurring themes.

None of this allows us to equate those findings with a Big Ball of Mud. It does support a more precise hypothesis: a long-lived Big Ball of Mud can create working conditions that resemble known strain factors. The effects of changes may remain difficult to predict, technical obstacles recur, responsibility and decision authority can diverge, ownership can stay unclear, workarounds can create rework, professional quality standards can conflict with what is realistically possible, and the perceived efficacy of improvement efforts may decline.

A Big Ball of Mud can create working conditions that burnout research recognizes as relevant strain factors.

The warning is therefore not that a Big Ball of Mud causes burnout. It is that occupational strain should not be reduced to workload alone. Low control, value conflicts, recurring obstacles, and perceived ineffectiveness also belong in the analysis.

Exhaustion does not only come from having too much work. It can also come from repeatedly seeing a problem, feeling responsible for it, and experiencing that your work can barely change its causes.

This sentence is a synthesis of the research discussed above and its transfer to software architecture, not an experimentally established causal claim about Big-Ball-of-Mud systems.

Strain does not arise from workload alone. Low control, value conflicts, and repeatedly experienced ineffectiveness are also established psychosocial strain factors.

A Personal Observation — and Its Limits

In one project observed first-hand, several people across the development teams were absent from work because of burnout. Over time, clear signs of strain also became noticeable for the author. What stood out from that personal perspective was that the strain did not primarily come from exceptionally long working hours. It came from repeatedly being able to see structural problems clearly, experiencing their consequences in everyday work, feeling responsible for improving them, knowing technically plausible approaches — and still having little ability to change the underlying causes sustainably.

That observation does not demonstrate a causal relationship between a Big Ball of Mud and burnout. Several cases inside the same project do not demonstrate one either. Too many other factors may contribute, and personal observations cannot replace controlled comparisons or longitudinal research. They do, however, open an occupational-psychology question worth asking:

What kind of strain arises when responsibility, professional standards, and actual influence remain misaligned over long periods?

This is where research on job control, Person–Environment Fit, and values congruence becomes particularly relevant.

When Professional Standards and Working Reality Diverge

The Areas-of-Worklife model treats Values as a distinct area alongside Workload and Control. It concerns the fit between what a person considers important in their work and what the actual work environment enables or demands. Maslach and Leiter describe mismatches in these areas as part of the organizational context of burnout. In a longitudinal study of 466 employees, they also showed that incongruities in areas of worklife were related to later movement toward burnout or engagement; fairness was one particularly relevant area in that study.

Research in other professions likewise shows that values are not reducible to workload. Leiter, Frank, and Matheson analyzed 2,536 Canadian physicians who worked more than 35 hours per week. In that cross-sectional study, both manageable workload and values congruence made independent contributions to predicting exhaustion and cynicism, while values congruence was also associated with professional efficacy. This is not evidence about software architecture, but it is a useful example of why occupational strain cannot be explained solely by hours worked.

The transfer to software remains theoretical. A structure-oriented developer may understand part of their professional role as eliminating underlying causes and making systems sustainably understandable. At the same time, an organization may have entirely legitimate economic reasons to prioritize the next incident and the next feature. These goals are not inherently contradictory; software has to deliver and be maintained. A misfit can emerge, however, when the second demand prevents the first from being pursued at all over a long period.

At that point the conflict is no longer only about whether a particular refactoring gets funded. It can touch professional identity: What does good work mean, and am I actually able to do that kind of work under these conditions? In the same system, the navigator may experience that difficult problems can reliably be solved, while the structure-oriented change agent experiences that every day is spent treating symptoms of a problem whose cause cannot be changed. Both experiences can be true at the same time.

When Voice Loses Its Expected Effect

Structure-oriented change often begins with Voice. In organizational research, Employee Voice refers to voluntarily communicating suggestions, concerns, or information about work-related problems with the intention of improving an existing situation. In software teams, it may sound very ordinary: “We should split this area differently,” “We need to remove this dependency,” or “We need clear ownership here.” These statements are initially the opposite of resignation.

Whether people keep using Voice also depends on whether they expect it to have an effect and whether raising problems feels useful and safe. Research on Organizational Silence examines situations in which relevant information or concerns are withheld. A recent experimental study by Andrieu and colleagues is particularly relevant to the dynamic discussed here: across two experiments with 654 participants, repeated experiences of low voice instrumentality made participants less likely to use later opportunities to speak up, and they reported increasing helplessness. The authors discuss this pattern as acquiescent silence through a learned-helplessness lens.

This was not an experiment with software architects and it was not a Big-Ball-of-Mud study. It does show, however, that a progression from repeatedly low perceived impact to less later Voice is psychologically plausible and empirically testable. The older Exit–Voice–Loyalty–Neglect model also describes different possible responses to dissatisfaction. These categories are not a fixed sequence and certainly not advice; they simply help explain why people may respond to the same situation by speaking up, waiting, withdrawing, or leaving.

That makes quick labels dangerous. When a long-tenured employee appears “resistant to change” today, the team may know the person’s current behavior without knowing the history of change attempts that preceded it.

The Three Patterns Can Be Stages in the Same Career

A developer may enter a project as a structure-oriented change agent, remove cycles, establish clearer responsibilities, add tests, and introduce technical rules. After several years, they may become more pragmatic and distinguish more carefully between problems that seem changeable and those that do not. They may stop reopening certain debates and accept some workarounds because previous attempts to remove them failed repeatedly. That can be sensible learning from experience; it can also move toward cynicism or resignation if the expected efficacy of structural change keeps declining.

At the same time, the same person keeps learning the existing system. They accumulate historical explanations, discover hidden relationships, and eventually know exactly the safe routes that new team members still have to learn. Many years later, yesterday’s structure-oriented change agent may have become one of the system’s best navigators.

Yesterday’s structure-oriented change agent can become tomorrow’s navigator.

None of this is inevitable. People can remain change agents, systems can genuinely improve, and working conditions can change fundamentally. The point is the direction of analysis. We usually ask how people change software. In a long-lived Big Ball of Mud, we also need to ask how the software environment changes the expectations and behavior of the people who work in it.

The response patterns are not fixed personality types. People can adapt their expectations and behavior to the existing environment over years.

Eventually the System Has a Social Operating Manual

Adaptation does not stop with long-tenured employees, because new developers do not enter a neutral system. Organizational Socialization research examines how newcomers learn to function within an organization. Bauer and colleagues’ meta-analysis used 70 unique newcomer samples and showed the importance of adjustment dimensions such as role clarity, self-efficacy, and social acceptance for later work outcomes and retention.

This research does not study Big-Ball-of-Mud systems; the following transfer is explicitly theoretical. In a well-structured software system, much of the orientation can be communicated by the code itself. Module boundaries, types, APIs, tests, and consistent patterns explain at least some of the rules. The less reliably those technical structures provide orientation, the more an organization may need other forms of knowledge transfer.

New developers then learn more than which API to call. They learn which person to ask about which subsystem, which areas have to be changed together despite apparently clear ownership, which components are better left untouched, which tests are trusted, which historical workarounds are considered unavoidable, and where formal ownership differs from actual decision authority.

A Big Ball of Mud eventually has more than a technical architecture. Around it, a social operating manual emerges.

That operating manual is not necessarily dysfunctional. On the contrary, without informal rules like these, a system that is difficult to understand may no longer be economically operable. The more important issue is where knowledge is being stored.

The less clearly the code expresses its rules, the more informal rules the team has to learn about how to work with it.

These rules are rarely documented completely. They are explained in reviews, passed on in pairing sessions, discovered during incidents, and corrected by experienced colleagues. Onboarding then consists not only of learning the software, but of learning how the existing organization has learned to live with that software.

Technically Chaotic, Socially Stable

This creates an apparent contradiction. The technical system may be highly opaque: responsibilities are difficult to trace, dependencies run in unexpected directions, special cases accumulate, and local changes can have distant consequences. The social system around it may nevertheless be surprisingly orderly because people know whom to ask, which parts need special attention during a release, which refactorings are unlikely to receive support, which workarounds are reliable, and what “usually” breaks.

The order no longer lives primarily in the code. Part of the stability comes from experience, routines, key people, collectively learned avoidance strategies, and expectations about what is still realistically changeable. That helps explain why some long-lived systems look almost unmanageable from the outside and still keep operating for years.

A Big Ball of Mud can be technically chaotic and socially remarkably stable.

That social stability is not automatically positive. It may simply mean that people have learned to compensate for technical instability reliably.

The less the system expresses its rules itself, the more the organization can develop informal rules for how to keep working inside it.

When the System Rewards Different Behaviors Differently

Discussions about poor legacy systems quickly invite simplistic labels such as “the good developers leave” or, conversely, “only bad developers accept this.” Both confuse the quality of people with their fit to a particular work environment. A more precise formulation is:

The system imposes different costs on different ways of working.

Someone who excels at remembering historical relationships, using informal communication paths, and navigating special cases safely may experience high effectiveness in this environment. Someone whose work is strongly oriented toward local comprehensibility, explicit ownership, and sustainable removal of root causes may encounter far more friction. That says nothing about who is the “better developer.” In another system, the cost structure may be reversed.

A navigator whose exceptional value rests on implicit knowledge of hundreds of special cases may have less of an advantage in a consistently structured greenfield system. A developer who repeatedly hits organizational constraints in a Big Ball of Mud may be highly effective in a system with clear responsibilities. A system therefore does not reward an abstract category of “good developer”; it rewards behaviors that are successful under its particular conditions.

A Big Ball of Mud does not only change people. Over time, it can also influence which behaviors are successful inside it.

Attraction, Selection, and Attrition

This opens a broader hypothesis. Benjamin Schneider’s Attraction–Selection–Attrition model argues that organizations do not consist of particular populations by accident over long periods. People are attracted to different environments, organizations select particular people, and some people whose fit remains poor leave again. In a later review, Schneider, Goldstein, and Smith found direct and indirect support for the central proposition that these processes can make organizations more homogeneous over time in certain characteristics.

That does not justify the claim that Big-Ball-of-Mud systems systematically “filter out” structure-oriented developers. There is no robust empirical evidence for that statement. Research on burnout and turnover in software engineering does not justify it either. It does show, however, that burnout, engagement, job resources, and retention can be related. Trinkenreich, Santos, and Stol studied more than 13,000 employees in one global IT organization and enriched survey data with actual employment status 90 days later. Their model links job resources, burnout, and engagement with intention to stay and actual retention, with some differences across subgroups.

A more cautious hypothesis is sufficient:

If the same work environment imposes persistently different costs on different ways of working, turnover can influence over time which people and behaviors remain in the system.

People whose capabilities fit a navigation-intensive environment may experience lower adaptation costs. People who can pragmatically accommodate it may as well. Someone who experiences a persistent misfit between professional standards and actual influence may face higher costs and may be more likely to leave. This is a theoretical transfer of general fit, attrition, and ASA models to a software environment, not an empirically established BBOM rule.

The hypothesis still has an uncomfortable implication. If people with lower fit leave disproportionately often while people with higher fit remain, the organization that remains can become increasingly well adapted to the existing system over time — not because anyone designed that outcome, but because adaptation and attrition operate for years.

Socialization and Attrition Can Reinforce the Same Direction

Two ordinary organizational processes now meet. Socialization changes how people work in an existing environment; attrition changes which people remain part of that environment over the long term. In a long-lived Big Ball of Mud, both processes can operate in the same direction without anyone deliberately coordinating them.

New employees learn the existing informal rules, long-tenured employees become better navigators, previous change initiatives shape expectations about new ones, and some people adapt their way of working. Others continue to experience strong misfit or leave. After many years, the resulting social system can therefore be much more stable than the technical structure would suggest. The organization has learned to compensate for the system, while the system has indirectly helped determine which skills, expectations, and routines are especially valuable in that organization.

Turnover Can Feed Back into the Technical State

Turnover is not only a possible outcome; it can itself create new difficulties. One possible feedback loop runs from structural complexity to high learning and navigation costs, then to stronger strain or poorer fit for some developers. If turnover follows, historical system knowledge disappears; the remaining experts become more important, epistemic dependency may increase, and fundamental change can become even harder.

This is not a law of nature. Departing employees can be replaced through well-documented knowledge, new team members can deliberately improve structure, and turnover can even break entrenched social patterns. But in a system whose operability depends heavily on implicit historical knowledge, the loss of experienced people is particularly expensive.

That closes the loop to the key-person paradox discussed earlier. The less the software itself explains how it works, the more important the people who can provide that explanation become. The more important those people become, the harder it may be to change the system fundamentally without them — and the longer the work environment persists to which everyone else has to adapt.

Perhaps the Most Dangerous Stability Is the One That Works

A Big Ball of Mud does not have to visibly collapse every day. Long-lived systems often demonstrate the opposite. Releases happen, incidents are resolved, features go live, experts know the critical areas, teams develop routines, and new developers learn the special cases. The organization keeps producing software.

Technically, such systems can be deeply problematic while a highly capable social compensation system has grown around them. That can make change even harder because a technical improvement no longer affects code alone. It may alter knowledge, responsibilities, routines, status, expectations, and capabilities developed over many years.

The navigator may lose some of the advantage created by historical knowledge. The adapted developer is suddenly asked to believe in another modernization effort after several earlier ones failed. The structure-oriented change agent encounters people whose current behavior is entirely rational given their own project history. None of them has to behave irrationally, and none has to actively want to preserve the Big Ball of Mud. The system can remain stable anyway.

What the Research Says — and What This Article Infers

With a topic that can quickly slide into psychological diagnosis or moral judgment, the boundary between evidence and transfer is crucial. It is well established that working conditions such as low control, high demands, low resources, role ambiguity, insufficient support, and different forms of misfit are associated with burnout dimensions and other measures of strain. Meta-analyses and longitudinal findings exist for several of these factors. It is also empirically established that these questions matter in software development and that burnout, engagement, and retention can be related.

Person–Environment Fit, organizational socialization, Employee Voice and Silence, and Attraction–Selection–Attrition processes are also well-established fields of research. They provide concepts and mechanisms that can describe observations from long-lived software systems more precisely.

What has not been directly established is that a Big Ball of Mud causes burnout through exactly these mechanisms, drives structure-oriented developers out, or inevitably creates a particular team culture. Those are theoretically grounded transfers. They fit observations from long-lived software systems, but they should be expressed as hypotheses about what can happen, not as psychological laws of legacy code.

That boundary does not weaken the diagnosis. It makes it more defensible.

Conclusion

A Big Ball of Mud does more than change code. Over years, it can influence which capabilities become especially valuable, which risks people are still willing to take, which change efforts they consider realistic, and which informal rules newcomers have to learn.

Some people learn to navigate a difficult system exceptionally well. Others lower their expectations of fundamental change and focus on known, safe paths; that can be sensible pragmatism, but after repeated unsuccessful change attempts it can also turn into cynicism or resignation. Others keep trying to create structure and may experience a strong conflict when professional standards, felt responsibility, and actual influence remain misaligned for a long time.

None of these patterns is a fixed personality trait. Yesterday’s change agent can become tomorrow’s navigator, and today’s skeptical colleague may have a long history of unsuccessful Voice behind them. New developers learn not only the repository but also the social operating manual that the team has built around it. If different ways of working incur persistently different costs in the same environment, socialization and turnover can also influence which behaviors remain in the system.

A surprisingly stable social order can therefore grow around software that is becoming increasingly difficult to understand technically.

A Big Ball of Mud can be technically chaotic and socially remarkably stable.

Eventually it consists not only of dependencies and historical special cases, but also of expectations, routines, and informal rules about how people behave around it. What an individual should do with that realization is a different question. It belongs in the later article “Change it, like it or leave it.” This article stops at the diagnosis.

Eventually, it is no longer only the software adapting to the organization. The people begin adapting to the software.

References

• Alarcon, G. M. (2011): A meta-analysis of burnout with job demands, resources, and attitudes. Journal of Vocational Behavior, 79(2), 549–562. DOI: 10.1016/j.jvb.2011.03.007.
• Andrieu, C. F. A., Milhabet, I., Denis-Noël, A. & Steiner, D. D. (2024): Voice in the Void: From Voice to Acquiescent Silence over Time as Learned Helplessness in Organizations. Revista de Psicología del Trabajo y de las Organizaciones, 40(2), 103–118. DOI: 10.5093/jwop2024a9.
• Aronsson, G., Theorell, T., Grape, T. et al. (2017): A systematic review including meta-analysis of work environment and burnout symptoms. BMC Public Health, 17, 264. DOI: 10.1186/s12889-017-4153-7.
• Bakker, A. B. & Demerouti, E. (2007): The Job Demands–Resources model: state of the art. Journal of Managerial Psychology, 22(3), 309–328. DOI: 10.1108/02683940710733115.
• Bauer, T. N., Bodner, T., Erdogan, B., Truxillo, D. M. & Tucker, J. S. (2007): Newcomer adjustment during organizational socialization: A meta-analytic review of antecedents, outcomes, and methods. Journal of Applied Psychology, 92(3), 707–721. DOI: 10.1037/0021-9010.92.3.707.
• Kristof-Brown, A. L., Zimmerman, R. D. & Johnson, E. C. (2005): Consequences of individuals’ fit at work: A meta-analysis of person–job, person–organization, person–group, and person–supervisor fit. Personnel Psychology, 58(2), 281–342. DOI: 10.1111/j.1744-6570.2005.00672.x.
• Leiter, M. P. & Maslach, C. (1999): Six areas of worklife: A model of the organizational context of burnout. Journal of Health and Human Services Administration, 21(4), 472–489.
• Leiter, M. P., Frank, E. & Matheson, T. J. (2009): Demands, values, and burnout: Relevance for physicians. Canadian Family Physician, 55(12), 1224–1225.e6. PMID: 20008605.
• Maslach, C. & Leiter, M. P. (2008): Early predictors of job burnout and engagement. Journal of Applied Psychology, 93(3), 498–512. DOI: 10.1037/0021-9010.93.3.498.
• Maslach, C. & Leiter, M. P. (2016): Understanding the burnout experience: recent research and its implications for psychiatry. World Psychiatry, 15(2), 103–111. DOI: 10.1002/wps.20311.
• Morrison, E. W. (2014): Employee Voice and Silence. Annual Review of Organizational Psychology and Organizational Behavior, 1, 173–197. DOI: 10.1146/annurev-orgpsych-031413-091328.
• Morrison, E. W. & Milliken, F. J. (2000): Organizational Silence: A Barrier to Change and Development in a Pluralistic World. Academy of Management Review, 25(4), 706–725. DOI: 10.5465/amr.2000.3707697.
• Park, H. I., Jacob, A. C., Wagner, S. H. & Baiden, M. (2014): Job Control and Burnout: A Meta-Analytic Test of the Conservation of Resources Model. Applied Psychology, 63(4), 607–642. DOI: 10.1111/apps.12008.
• Reichers, A. E., Wanous, J. P. & Austin, J. T. (1997): Understanding and managing cynicism about organizational change. Academy of Management Executive, 11(1). DOI: 10.5465/ame.1997.9707100659.
• Rusbult, C. E., Farrell, D., Rogers, G. & Mainous, A. G. III (1988): Impact of Exchange Variables on Exit, Voice, Loyalty, and Neglect: An Integrative Model of Responses to Declining Job Satisfaction. Academy of Management Journal, 31(3), 599–627. DOI: 10.5465/256461.
• Schneider, B. (1987): The People Make the Place. Personnel Psychology, 40(3), 437–453. DOI: 10.1111/j.1744-6570.1987.tb00609.x.
• Schneider, B., Goldstein, H. W. & Smith, D. B. (1995): The ASA Framework: An Update. Personnel Psychology, 48(4), 747–773. DOI: 10.1111/j.1744-6570.1995.tb01780.x.
• Singh, P., Suar, D. & Leiter, M. P. (2012): Antecedents, Work-Related Consequences, and Buffers of Job Burnout Among Indian Software Developers. Journal of Leadership & Organizational Studies, 19(1), 83–104. DOI: 10.1177/1548051811429572.
• Trinkenreich, B., Santos, F. & Stol, K. J. (2024): Predicting Attrition among Software Professionals: Antecedents and Consequences of Burnout and Engagement. ACM Transactions on Software Engineering and Methodology, 33(8), Article 218, 1–45. DOI: 10.1145/3691629.
• Tulili, T. R., Capiluppi, A. & Rastogi, A. (2023): Burnout in software engineering: A systematic mapping study. Information and Software Technology, 155, 107116. DOI: 10.1016/j.infsof.2022.107116.