Introduction
Accountability is considered the link between individuals and their social system, creating an identity relationship associating individuals with their actions and performance. In the introductory series’ first article, Beyond Tools and Processes: Strategies for Successful Software Development Teams, we introduced the concept of accountability and proposed this definition:
The expectation of being held responsible for one’s actions and the need to provide explanations and reasoning for such actions to others in the future [4].
Irrespective of the nature of a collective, ranging from a dyad to a civilization, addressing coordination and collaboration amongst its constituent members with diverse interests is imperative. Accountability comes into play by establishing shared expectations in social systems. When standards and expectations are set, people must adhere to them, and the failure to do so may result in imposing penalties [3, 6]. Compliance with standards is evaluated at various layers of social systems, including the individual, the dyad, the group, the organization, and the society as a whole [3].
Accountability is a fundamental enabler in all societies, including their organizations. It’s absence in a social system may result in individuals acting with little regard to the consequences imposed by others. Consequently, organizations may find it challenging to effectively manage their operations [3]. In software development, accountability has been acknowledged in pioneers’ work as far back as the 80s. In Barry W. Boehm’s paper on the “seven basic principles of software engineering,” he proposed one principle on ensuring accountability for outcomes, i.e., “maintain clear accountability for results” [2]. Furthermore, “accountability” appears nine times in the Scrum guide [7]. The guide has a strong emphasis on accountability as a control mechanism, for example, “holding each other [developers and team members] accountable as professionals” [7]. Then, how does accountability control and improve outcomes in software teams?
Figure 1 is a visual representation of the process of holding one accountable. It consists of an evaluation process where individuals are held accountable for their actions and decisions, guided by interpersonal, social, and structural factors within specific sociocultural contexts. Performance against predefined rules, standards, official and unofficial expectations, and shared norms is assessed by an audience, resulting in the dispensation of rewards or sanctions. In response, individuals develop various coping mechanisms, both proactive and reactive, to safeguard and maintain a consistent self-image within their social system. Some of these mechanisms may include cognitive strategies as aligning actions with audience preferences or retrospective rationalization, where individuals defend past behaviors with justifications and excuses. While traditional accountability theory has often treated the “audience” as a singular entity, it can be deconstructed into a web of multiple parties to whom the individual is answerable [5].
Outcomes
In our recent work [1] on the topic, Understanding the building blocks of accountability in software engineering, we reported that software team members are being individually and collectively accountable for several
Figure 1: The Dynamics of Accountability in Social Systems
projects’ outcomes, mainly software quality, software security, and meeting projects’ deadlines. Business analysts share the accountability of these outcomes with other roles in software teams.
Business analysts (BAs) share accountability for software quality, security, and project deadlines because their role involves defining requirements that directly impact these outcomes. By gathering and translating business needs into technical specifications, BAs ensure that the software meets quality standards and functions as intended, which is integral to minimizing defects and security vulnerabilities. Additionally, their role in producing requirements artifacts to build software influences timelines, aligning team efforts with project deadlines. When BAs fail to deliver accurate and timely requirements artifacts, it has an impact on timelines. Therefore, making them accountable alongside developers and other team members.
Formal Accountability
Organizations intentionally implement strategies to drive accountability among software team members. These institutionalized drivers include financial rewards, career advancement, and punishment. These formalized strategies influence individuals’ perceptions of accountability, thereby shaping their commitment to achieving the intended outcomes of their teams. While rewards intend to reinforce positive performance, punishment is designed as a deterrent, discouraging engineers from underperforming by making them aware of the potential negative consequences.
Financial rewards. In the abovementioned work [1], we found that software team members are partly motivated to meet established expectations, driven by the prospect of financial rewards. Some of these rewards include financial incentives, specifically the annual bonus tied to performance reviews. Financial rewards, whether in the form of bonuses, raises, or promotions, are used to uphold accountability and motivate individuals to meet established expectations.
Career advancement. Achieving career growth has also been cited in our work as an incentive to feeling accountable. Organizations reward meeting expectations for the intended outcomes with career advancements. Our findings show that the drive to receive advancements in software professional careers is closely tied to demonstrating a strong sense of accountability.
Punishment. Organizations employ punishment-based strategies for underperforming team members to incentivize them to meet or exceed the established expectations for intended outcomes. Punishment-based strategies range from corrective measures, such as performance improvement plans, to loss of employment. Punishment-based strategies show that, in some instances, organizations are committed to driving account- ability among software professionals by implementing clear consequences for failing to meet expectations.
Control mechanisms are the various processes, tools, and procedures put in place by the organization or embedded within software development practices to ensure that individuals are accountable for meeting their responsibilities and adhering to established expectations. Within the dynamics and process of accountability, control mechanisms fit under “evaluation”, in figure 1. To control institutionalized formal accountability, performance evaluation is carried out periodically as an accountability exercise. These periodic assessments drive accountability because they demand answerability to the organization on performance against predefined expectations, relying on metrics like defect counts in the code and feedback from peers, ensuring that engineers, for example, consistently work towards meeting or exceeding the organization’s established expectations.
Shared Accountability
Shared or informal accountability emerges from peers’ expectations and the software professionals’ intrinsic drive. While the former promotes a sense of collective accountability, where individuals feel compelled to reciprocate and demonstrate their accountability to their peers, the latter is innate and intrinsically grounded. When feeling intrinsically driven to achieve certain outcomes (e.g., code quality or meeting deadlines), software professionals manifest a self-driven accountability. This self-imposed answerability is rooted in a personal desire to excel or meet self-imposed standards, reflecting software professionals’ internal commitment and motivation to uphold and align the quality of their deliverable with their professional and personal values. Shared accountability is mainly reinforced by software engineering and development practices (i.e., testing and code review) and peers’ feedback.
This peer-based accountability uses control mechanisms inherent to software development practices, such as testing or informal peers’ feedback, outside established organizations’ processes like performance reviews.
Informal or shared accountability is attributed to the shared norms of the group [1]. However, the rewards are not similar to formalized accountability (i.e., financial rewards and career advancement). In software development environments, software professionals feel accountable towards their peers’ expectations to receive appraisals from their peers and contribute to the collective endeavor. In addition, sanctions at the team level are avoided. Instead, our work shows that the software teams prefer a psychologically safe approach to underperforming.
Software professionals’ accountability is influenced not only by institutionalized mechanisms (e.g., perfor- mance evaluation) but also by peers’ expectations and intrinsic motivation. While traditional accountability control mechanisms like performance have their relevance in the context of software teams, they co-exist with peer-driven and intrinsic motivation-driven accountabilities. Our work [1] shows that software professionals have a natural inclination towards peer-driven and intrinsic motivation-driven accountabilities. Therefore, in the next article, we will dive deeper into how this type of accountability transpires and contributes to meeting the expectations of teams’ outcomes.
Author: Adam Alami
Adam Alami is an assistant professor with Aalborg University, Denmark. He has broad experience in information technology practices. His career began in software development, before progressing to include business analysis and project management. Involvement in major IT transformation projects has for twenty years been the mainstay of his work. His chosen fields of research fit within the broad topic of cooperative, social, and human aspects of software engineering. He has a keen interest in business analysis and contemporary software development practices. He holds a PhD degree in Computer Science from the IT University of Copenhagen, Denmark, a Master degree in Computer Science from the University of Technology (UTS), Sydney, and a Bachelor degree in Software Engineering from the Université du Québec à Montréal. Email: [email protected]. Twitter: @AdamAlamiDK.
References/footnotes:
- A. Alami and N. Ernst. Understanding the building blocks of accountability in software engineering. In Proceedings of the 2024 IEEE/ACM 17th International Conference on Cooperative and Human Aspects of Software Engineering, pages 153–163, 2024.
- B. W. Boehm. Seven basic principles of software engineering. Journal of Systems and Software, 3(1):3–24, 1983.
- D. D. Frink and R. J. Klimoski. Toward a theory of accountability in organizations and human resource management. 1998.
- D. D. Frink and R. J. Klimoski. Advancing accountability theory and practice: Introduction to the human resource management review special edition. Human resource management review, 14(1):1–17, 2004.
- M. J. Gelfand, B.-C. Lim, and J. L. Raver. Culture and accountability in organizations: Variations in forms of social control across cultures. Human Resource management review, 14(1):135–160, 2004.
- B. R. Schlenker, T. W. Britt, J. Pennington, R. Murphy, and K. Doherty. The triangle model of responsibility. Psychological review, 101(4):632, 1994.
- K. Schwaber and J. Sutherland. The scrum guide. Scrum Alliance, 21(19):1, 2020.