Contents 
To create new technologies, developers must collaborate well on complex code in an iterative and distributed manner. Developers and their teams also need to balance personal productivity, project constraints, organizational context, and business impact alongside pushing the boundaries on what code can do in the world. Against this complexity, some estimates of the overall success rates of software projects claim that the majority of software projects deliver late, deliver out of scope of planned budgets, and fail to drive business impact.1
Introduction
How can software teams thrive in the face of the unexpected and unplanned difficulties of software projects? This study contributes a theoretically grounded model for the workplace-specific sociocognitive drivers of developer thriving that promote productivity. We believe this model is an important tool for leaders and teams who seek to better define tractable and attainable targets for interventions and wish to include developers’ well-being and needs as knowledge workers as they make decisions about team and organization design to yield productivity outcomes
Background Research
Understanding what unlocks high-quality problem-solving for developers is key to maintaining software innovation. Nevertheless, software engineering as a field does not have a consensus on the measurement of developer productivity.2 Absent a clear shared definition, working teams and engineering leadership frequently fall into one of the two measurement traps when attempting to define and subsequently increase developer productivity inside of their engineering functions, which lead to different behavioral outcomes:
Fixating on surface definitions of productivity and measuring and incentivizing the wrong things. Outcomes may include limited or punitive production measures, such as counting lines of code, and failures to account for tech debt.
Becoming paralyzed by complexity and measuring and incentivizing nothing. Outcomes may include poor organizational practices such as relying heavily on interpersonal coordination3 or gut instinct in technical decision-making and evaluation of performance, which is subject to many potential biases.
While these two maladaptive scenarios for engineering organizations may seem opposing, they both spring from a foundational lack of clarity on what truly helps developers to achieve long-term success in sustaining productivity and, therefore, how to measure and incentivize it.
However, previous evidence on the factors that impact developers’ achievement provide a starting path through these measurement traps. Software researchers have called out the need to develop new models of human-centered developer productivity by 1) investigating the sociocognitive factors that improve problem-solving during coding and software work overall, 2) doing research directly on the real-world experiences of modern software teams, and 3) avoiding major misconceptions in measuring productivity, such as defining developer productivity only as crude output measures such as lines of code or setting a single metric goal and using it as a threshold to evaluate all software work regardless of differing contexts and needs.4,5,6 The Satisfaction, Performance, Activity, Communication and Collaboration, and Efficiency and Flow (SPACE) framework, which characterized developer productivity in terms of satisfaction and well-being, performance, activity, communication, and efficiency, is one recent example of software research that proposes a multivariate theory that includes psychological drivers of developer productivity.5 The SPACE framework provides possible examples of systematically broadening “productivity” definitions with dimensions such as job satisfaction. Nevertheless, while the SPACE framework definition includes satisfaction and well-being as key pieces of productivity, it does not provide psychometric evidence for how to measure and evaluate developer satisfaction and well-being at scale. Psychometric evidence is defined as quantitative evidence about underlying latent variables that are believed to drive psychological processes. Because psychological constructs are not directly observed, reliable estimations of psychological constructs rely on developing measurements that use empirical approaches such as the use of validated items, reliability reporting, and adherence to previously validated constructs.7 A psychometrically evidenced alternative to focusing on a general “satisfaction” construct is developer thriving, the process of sustainable growth and development.8
A Framework for Developer Thriving
The developer thriving framework presented in this study is adapted from previously validated models of thriving in psychosocial and workplace contexts and consists of four factors: developer agency, developer motivation and self-efficacy, developer learning culture, and developer support and sense of belonging (Table 1).8
The framework builds on the known connection between developer satisfaction and productivity to answer what drives satisfaction in the first place. Notably, the four factors in developer thriving explicitly call attention to the environmental and structural affordances that create the conditions for developer productivity. One central criticism of relying on happiness and satisfaction measures is that they are highly volatile and may capture immediate signals (e.g., mood) rather than true overtime productive patterns.9 In contrast, the four sociocognitive factors of developer thriving each tie explicitly to behavioral cycles that maintain high performance over time using trait-based (rather than state-based) measures adapted from previously validated measures, thus yielding a more long-term and sustainable measure.7,8,10
What Might Increase Developer Thriving? Visibility and Healthy Metrics Use
Along with developing new original measures for what key factors play into developer thriving, we also wanted to ask what leaders and organizations can do to increase developer thriving. Based on the literature, we identified two potential factors: visibility and value of work and healthy metrics use (HMU).
The unique benefit of both expecting and planning for visibility, and getting feedback from a visibility cycle, is supported across scientific evidence on human well-being, health sciences, and organizational psychology. For example, research on behavioral change in healthcare settings highlights the value created from recognition and visibility as one of the strongest predictors of behavioral engagement, performance, and productivity of both individuals and team members.11,12 This impact on developer motivation was also a key theme underlined by both individual contributor developers in the pilot testing for this study, who described expecting and anticipating moments of recognition as key motivators, and by managers, who described a pivotal responsibility of making their team’s work visible.
Increased measurement leading to positive outcomes echoes a significant body of research in the clinical and behavioral sciences, which indicates that we tend to forget or lack awareness of the amount of work we have done, leading us to devalue and minimize our progress. Tracking behavioral and psychological processes has been shown to mitigate this effect by providing us concrete evidence of our progress and accomplishments. Having this evidence not only increases mindful attention and awareness but also increases our sense of value and mastery over our work, increases empathy and self-compassion, boosts coping abilities and distress tolerance, empowers us to recognize and set boundaries, and drives behavioral engagement for both groups and individuals.13 With developers specifically, research has found that self-reflection in a repeated cadence increased developers’ awareness of their habits and led to positive behavior change for both output and well-being.14
Based on this previous literature, we developed the following six key hypotheses:
HMU will be positively associated with perceived productivity.
Visibility and value of work will be positively associated with perceived productivity.
Developer thriving will be positively associated with perceived productivity.
Visibility and value of work will be positively associated with productivity through developer thriving (mediation).
HMU will be positively associated with perceived productivity through developer thriving (mediation).
HMU will be positively associated with perceived productivity through visibility and value of work (mediation).
Methods
Our study consisted of a large-scale quantitative survey. This section discusses the quantitative survey measures (the “Survey Measures” section), survey sample recruitment and description (the “Survey Sample Recruitment and Description” section), and survey analysis approach (the “Survey Analysis Approach” section).
Survey Measures
Throughout the quantitative measures on this survey, participants answered using a Likert-type scale. Unless otherwise indicated (see Table 2), the scale included a neutral midpoint; scores greater than 3 indicate agreement, while scores less than 3 indicate disagreement. For each multi-item measure, the items were averaged to create a single composite score for each measure.
Perceived productivity rating (PPR): There is no standard measure for developer productivity,6 and developers define productivity in multiple ways; software research has therefore frequently used self-report ratings of productivity.14 To operationalize this complex concept, we also chose to ask developers to rate their own productivity over a recent period of time. This approach allows us to let developers summarize across their complex contexts, different industry paces of work, and working environments. In our study, the PPR is a self-report, single-item measure. In keeping with our aim of reducing within-survey response effects, this question was shown first to reduce biases that might arise from respondents’ reflecting on questions about belonging, measurement, and software metrics.
HMU: HMU was operationalized as a two-item composite rating created for the purpose of this study. The first item asked participants to report their team’s use of metrics. The second item asked participants to report if they believed their team used the “right” metrics for their team and agreed that “they measure the right things.”
Developer thriving scale (DTS): The DTS is a ten-item measure created for the purpose of this study, abbreviated in order to be accessible to participants at scale in an applied research setting (see full details in the supplementary materials available at https://doi.org/10.1109/MS.2024.3382957). The measure draws from models of thriving in health and psychology to identify four primary factors: motivation and self-efficacy, support and belonging, learning culture, and agency. The items for each factor are adapted from empirically validated psychological measures of these constructs. The measure had good internal consistency in our sample (a = 0.86).
Visibility and value questionnaire (VVQ): The VVQ is a three-item measure created for the purpose of this study. The measure draws from previous research indicating that recognizing and valuing employees’ work predicts employee satisfaction and asks respondents to rate the extent to which they believe their technical work is visible and valued by teammates and managers. The measure had good internal consistency in our sample (a = 0.83).
We pilot-tested the clarity of our survey by seeking feedback from five full-time software engineers within our organization. To reduce response biases within survey, we used a semirandomized survey design. All participants answered key construct measures before being asked to answer measures that may influence their responses. For example, to avoid stereotype threat, participants rated their productivity before being asked to answer any questions about demographic characteristics. Within the key construct measures (Table 1), the order of presentation was randomized to control for order effects.
Survey Sample Recruitment and Description
We utilized snowball sampling and advertised our online Qualtrics survey publicly on various social media (e.g., X [formerly known as Twitter], Facebook, Mastodon, LinkedIn, and Reddit) from researchers’ personal social media accounts and via direct e-mails to professional listservs of interest to developers. Our survey was also advertised inside the Pluralsight Skills platform, embedded in developer-relevant content pages such as internal learning programs, and inside the Pluralsight Flow platform, shown as a banner advertisement to professional developer users. In all cases, this survey advertisement was optional and not connected to user data on either of these platforms. All participants provided consent and were informed of the Developer Success Lab’s consent and participant privacy policies. Because our study design consisted of a survey study with a sample of adults who provided consent to participation and whose data were anonymized, it was determined to be exempt from the requirement to be reviewed by an Institutional Review Board (Category 2).
Our survey was open to all full-time individual contributor developers and software engineers responsible for technical code work in their role. We recruited a total of 1,409 individual contributor developers. Of the 1,409 participants, 121 did not move past the first two questions of the survey, and 6 were removed for writing identity-based discriminatory responses in our open text demographic fields. Our final sample consisted of 1,282 participants. A summary of demographic and firmographic characteristics can be seen in Tables 2–6. As a token of appreciation for participation, our research team made a donation to an open source software nonprofit, chosen based on participant voting.
Survey Analysis Approach
To test the normality of our variables, we obtained skew and kurtosis values of all variables. All variables were within normal ranges. As such, we performed a Pearson’s correlation to check the correlations among all variables (see Table 7).
To identify covarying demographic and firmographic variables, we conducted a series of correlations among our primary variables of interest and our continuous demographic and firmographic variables. To avoid potentially misleading signals resulting from the reduced sample size and highly skewed distributions across categorical identity questions, we did not examine the relations among our primary measures and our categorical demographic and firmographic variables. Years of coding experience were positively associated with the VVQ [r(701) = 0.20, p < 0.01], DTS [r(472) = 0.21, p = 0.001], and PPR [r(710) = 0.25, p < 0.001]. Additionally, the percent of time spent writing code was positively associated with the HMU [r(719) = 0.09, p < 0.05], PPR [r(730) = 0.20, p < 0.001], DTS [r(494) = 0.27, p < 0.001], and VVQ [r(722) = 0.16, p < 0.001]. There were no other significant effects among our primary measures and the other firmographic and demographic variables (p = 0.07–0.84). As such, we controlled for the effect of the percent of time spent writing code and years of coding experience in our analyses.
To test hypotheses 1–6, we conducted a serial mediation path analysis (see Figure 1 for model structure). This allowed us to simultaneously test if the HMU, VVQ, and DTS were positively associated with the PPR (hypotheses 1–3). This statistical model also allowed us to test if the VVQ was positively associated with productivity through or because of developer thriving (mediation; hypothesis 4) and if the HMU was positively associated with perceived productivity through or because of the DTS and the VVQ (mediation; hypotheses 5–6).
The developer thriving serial mediation model results. Standardized regression coefficients are represented.
Results
Findings
From previous research,5 a positive developer experience and increasing developer satisfaction are suggested to be among the best ways to increase developer productivity. Our study aimed to provide more actionable and measurable factors in developer experience than simple satisfaction and looked at whether the factors in developer thriving are predictive of productivity. Further, this study asked if implementing team-level tools and processes such as healthy metrics and increased visibility could improve developer thriving and productivity, even after controlling for factors like years of experience and time spent coding.
To test our hypotheses, we conducted a linear regression-based serial mediation path analysis with the HMU as our independent variable, VVQ as our first mediator, DSS as our second mediator, and PPR as our outcome variable (saturated model using only observed variables; CFI = 1; RMSEA = 0). Additionally, we entered the percent of time spent coding and years of coding experience as covariates for all variables, given their significant associations with our mediators and outcome variable.
With all variables in the model, we found that HMU, visibility and value of work, and developer thriving were all significantly associated with perceived productivity (hypotheses 1–3), with developer thriving having the strongest effect on perceived productivity. Notably, thriving also mediated the relations between perceived productivity and both HMU and visibility and value of work, indicating that the other variables impact productivity partially because of thriving, identifying developer thriving as a key component of increasing productivity (Table 8 and Figure 1; hypotheses 4–5).
The model also indicated that healthy team metrics use and greater visibility and value of software work were both significantly associated with greater developer thriving, with visibility and value of work having the stronger effect on thriving. Visibility and value of work also mediated the relations between HMU and both developer thriving and perceived productivity, highlighting visibility and value of work as a key lever for increasing both thriving and productivity (Table 8 and Figure 1; hypothesis 6).
Finally, HMU was associated with greater visibility and value of work, highlighting HMU as one factor for creating visibility and value of software work (Table 8 and Figure 1).
Limitations
The results of our study should be considered in the context of several limitations. First, our study utilized a survey design. As such, there may be a response bias in who responded to our survey, resulting in limits to generalizability. There may also be the potential for a social desirability bias in reporting, although this was mitigated through the use of anonymized data collection methods.
Second, although our study represents a step toward empirically measuring developer thriving through our use of previously validated items, future research could build upon this work by conducting a full factor analysis to assess the performance of each factor of developer thriving in software contexts with a larger global population.
As is typical of most survey studies, our study utilized snowball sampling. Although this is an effective and accepted sampling method, it carries a risk of sampling bias that could limit the generalizability (external validity) of our findings.
Additionally, we operationalized our constructs using previously validated trait-based measures, which aim to capture average or overall characteristics and experiences across contexts. Although trait-based measures are more longitudinally stable than state-based measures,10 they can overlook context-specific experiences. As such, while our findings can be generalized to developers’ experiences overall, they are not universally applicable to every situation or context.
Finally, given that our data do not employ temporal precedence among measures, our analyses cannot yield causal conclusions but must instead be considered as analyses of associations temporally placed based on the existing literature. Under this stipulation, our analyses can indicate that there are significant relations among our variables but cannot statistically establish directionality among them. Although the proposed directionality of our model fits with current theoretical models of productivity, temporal precedence is necessary to make inferences about directionality.
Developers need thriving and all its elements inside their immediate problem-solving environment, but they also need to believe that their individual productivity will go beyond their teams.
Our findings are consistent with previous software research that highlights satisfaction as the strongest predictor of developer productivity.5 However, our study provides evidence for a more rigorous, psychometrically tested measure that moves beyond developer satisfaction: the developer thriving framework, a multidimensional and longitudinally stable measure of the factors driving satisfaction in the first place. Additionally, our framework further expands on the connection between satisfaction and productivity to highlight visibility as the key to not only directly increasing developer thriving but also boosting the effect of thriving on developer productivity.
It is likely that the sociocognitive elements that create developer thriving are impactful because they create “virtuous cycles”: positive beliefs, perceptions, and expectations about code work and problem solving. These cycles work to reinforce developers’ sense of progress and problem-solving even and especially when developers encounter difficulty, friction, and failure. Across intervention science in human behavior, positive metacognitive beliefs, perceptions, and environmental factors have been found to drive longitudinal behavior change, leading to long-term achievement.15 Organizations can either enhance or subvert these important cycles: when teams and organizations put effort into creating a positive problem-solving culture, it sustains long-term achievement, iterative improvement, and reflective, collaborative problem-solving.
That is, developers need thriving and all its elements inside their immediate problem-solving environment, but they also need to believe that their individual productivity will go beyond their teams. Our visibility and value and HMU constructs are a step toward naming and measuring the missing pieces that helps explain an important connection between individual developer productivity and thriving and how the organization’s measurement, valuing, and recognition of developers flows back down to software teams.
Taken together, the findings suggest that organizations can improve developer productivity in a human-centered way by improving developer thriving, for example, by considering factors such as enough learning time, strong supportive cultures, the opportunity to give feedback, and recognition for effort work and difficult problem-solving. Additionally, organizations can further unlock the benefits of thriving by making developers’ work both visible and valued, for example, by using shared, accurate measures of software work, paying special attention to teams or types of engineering work that do not get shared broadly, and investing in systems that explicitly recognize and reward teams for the technical progress they make, particularly work that was unexpectedly challenging, required new skills, or fixed long-standing problems.
ACKNOWLEDGMENT
The authors thank each of our participants for their participation and support. Catherine M. Hicks and Carol S. Lee contributed equally to this work. This work involved human subjects or animals in its research. The authors confirm that all human/animal subject research procedures and protocols are exempt from review board approval. This article has supplementary downloadable material available at https://doi.org/10.1109/MS.2024.3382957.