Anujah Bosman.
The recent headlines about Eskom, Elon Musk’s actions at Twitter, the leadership crises at esteemed universities, our South African political landscape and the rife corruption in the private and public sector, leaves you with no option but to reflect about leadership. It has left me pondering about how to lead in these scenarios. As with all my ponderings, the parallels between business and the world of software development are stark and obvious. This article is based on my observations across many business domains and software projects. It highlights the similarities between software development and the situation. It also describes how the same situation is handled differently in software development.
The Eskom management interventions that we read about are probably very familiar to many software practitioners. The story is believable to us and we can only imagine the many meetings that were held to request additional resources from senior management. A likely outcome is that each time resources were requested, the iron triangle of project management that consists of the trade-offs between cost, time and quality would have surfaced. Since cost and time are always critical to business, it is most likely these were fixed, resulting in quality being compromised. Technical debt steadily builds up and since the system is always in firefighting mode, the debt grows and it eventually becomes unmaintainable. New engineers and teams work around the debt to deliver short-term solutions without thinking about the current and future edge cases (there is no time or enough of experienced engineers around to enrich the context), resulting in failures and even more complexity to unravel. Rock star engineers are heavily relied on and there is never enough time to build or transfer skills, deal with technical debt or upgrade systems. Senior board members and “higher ups” start shouting and peddling promises to customers to buy some time. In the interim, engineers are on the death march and new resources promptly get added to the team. The team is tired and disillusioned and suffers from the mythical man month. There is a lot of blame, conflict and resentment between the existing team and the new “experts” who have been brought in to fix the problem. In the interim, there are many contextual factors that continually bombard the environment and the participants causing unnecessary stress, context switching and a diversion of energy and resources. The CEO and project managers are busy and are continually in meetings about meetings to manage perceptions. Eventually, the level of dissatisfaction cannot be contained and the management style shifts from consultative to autocratic. Engineers and forces within the system revolt in various subtle and not so subtle ways, causing the system’s performance to worsen and degrade.
When we encounter problems in business, we usually adopt an engineering perspective that assumes the system can be decomposed into smaller parts where linear causality is applied to unravel the mess. It is worth using the Cynefin framework to understand the situation better before applying linear causality. Linear causality assumes that anything that happens in the system can be traced to a previous occurrence. If the live system is chaotic and unpredictable, where it’s not possible to isolate a single variable and control everything else in order to determine a variable’s contribution, we should assume that we can safely assume that is a complex system. Making a change will create both positive and negative effects anywhere in the causal web. This is particularly true if there are divisive agendas, power plays and politics that impact decisions and actions on technical or engineering systems. It is therefore important to continually monitor and add to the causal web. Managing and leading in complexity requires leaders to be able to operate at multiple levels within the organisation. It requires leaders to actively listen and interact at all levels, collecting signals and data. This leadership style is not “fluffy”, it requires using multiple leadership styles, being process-oriented and gathering social influence and currency via interactive interaction.
The leader must enable change and recognise that there are external and internal forces and a high level of interdependency that cannot be systematically broken down into linear causal relationships.
In software development, high levels of complexity necessitate leaders to create a culture of shared leadership, where there is sharing of power and influence, while one person remains in charge. It requires collaboration and ensuring that there is autonomy to make decisions that directly impact on your work. Shared leadership must have an enabling environment that is actively created and maintained. The environment must have transparency, it must be a safe environment and it must support autonomy. In software development, an enabling environment is facilitated by the practices, tools and working agreements. Trust is built by what we do rather than what we say. Shared leadership requires that the leadership team understand their role and purpose in working together to lead. It also assumes that a critical mass in the team is competent and has the required skills.
Software development also requires that leaders practice situational leadership. Situational leadership requires leaders to use the correct leadership style based on the maturity of the system. If employees lack accountability and skills then an authoritarian leadership style is suited. If employees are motivated but need a lot of guidance, then a coaching leadership style is applied. If employees have the skills to perform the tasks but may lack confidence, then a supportive style is needed and if employees are highly motivated, competent and know what to do, then the leadership style requires more delegation. These differing leadership styles are regularly used in software development when dealing with a mixed team of juniors, intermediates and seniors.
Although leading and managing well in software development is complex, it is still easier than in business because the focus in software development remains squarely on the software and not on power or influence. It’s also easier to continually sense and adapt to contextual factors and unforeseen complexity because software is delivered frequently, in small iterations. This allows leaders to continually reprioritise the next actions so that it adds the most business value now, thereby catering for emergent and unknown factors or shifting priorities. It gives leaders time to make a change and assess how the complex web of interactions are affected.
Recently, we have seen a slew of corruption and “rockstar leaders” being heralded to fix the broken system. This leader is charismatic and we all initially love them. The organisation is hidden and the systems and practices that allowed corruption to flourish are never discussed. The charismatic leader becomes the new face of the organisation. Charismatic leaders are needed during a crisis, since their confidence helps us to believe that things will be “fixed”. Their confidence leads us to believe they are competent. Recently, we witnessed the fallout of this assumption with Elon Musk and his first days at Twitter. It is important to note: “Competence is how good you are at something. Confidence is how good you think you are at something. Competence is an ability; confidence is the belief in that ability.” – Chamorro-Premuzic, Tomas; and “Why Do So Many Incompetent Men Become Leaders?” (p 20) – Harvard Business Review Press.
Ultimately, in the technical domain of business and software development, EQ is important, but the most important factor that garners respect is a leader’s intellectual capital, ie, that is domain specific expertise, a wealth of experience and good judgment. Even if a leader has EQ and strong intellectual capital, a leader may fail because of the context in which they find themselves. There has to be alignment between the leader’s values and the current values and practices that exist in the organisation. If there is minimal alignment, there will be conflict and much churn before a dominant culture wins.
We are being presented with rich case studies of leadership in crises. It is easy to critique a leader, but we must also acknowledge our roles in developing and nurturing narcissistic leaders or leaders who tell us what we want to hear. We need leaders who are judged by the output, who build winning teams, who are competent and have integrity and whose performance is integrally tied to his or her teams’ performance. It is my belief that leadership is a function of an organisation and it is not a glamorous end destination that we need to aspire to or worship as the pinnacle of success. A leader must serve his or her people and his or her organisation.