This summer I wrote a long essay about shame and software projects. Shame is a topic I’ve been thinking about for nearly 30 years, so the gestation period for the essay was unusually long. I wanted to capture here some of my context and motivation for writing it.
As I’ve written before, working in and around government has highlighted for me the extent to which people in public service will avoid taking risks. The shame essay is my attempt to understand why risk avoidance is such a strong institutional and cultural norm.
Public servants avoid risk because they are trying to avoid the shame of failure. The “public” in public service means that the fallout from what might otherwise be a “normal” failure ratchets up the sense of exposure. In government, failure can mean public scrutiny, investigations, inspections, audits, newspaper headlines, coupled with the internal personal sense that the value of the work is so crucial and that so many people are relying on us to do it well. High ideals, high stakes, a field ripe for shame events.
When it comes to information technology, a field that continues to evolve at a blistering pace, the patterns of shame avoidance are even more acute. The most common phrases about technology I hear from people in government, sometimes at the highest levels, are variations on “I’m not a tech person” and “I don’t understand how it works.” These statements are ways of lowering expectations, and therefore lowering the risk of shame by shrinking the gap between the ideal and the real.
In our modern, interconnected world, especially in the middle of a pandemic with people reliant on unemployment websites and remote work environments, IT systems pose a huge risk to government’s ability to fulfill its mission. So somebody in government needs to know how the IT works. But for years we’ve consistently under-invested in our government IT systems and in the processes (hiring and procurement) that support them. We’ve made it risky to work in and around government IT, and perversely, we continue to make the problem worse by trying to outsource all that risk to private sector vendors.
So we end up in a vicious knot of low tech IQ capacity, poor risk management practices and shame. What I tried to lay out in the shame essay was how some Agile software practices can help cut the knot.
The Agile process grew out of response to the Waterfall model. All by itself the Waterfall model of software development is not rooted in shame. However, the way it has been applied, particularly in large organizational contexts like government, has reinforced cultures of shame. One reason is that Waterfall requires a careful and detailed (and often time-consuming) upfront articulation of the ideal final result, analogous to the ideal self. A long detailed list of requirements and a long development cycle incentivizes development teams to build to the plan rather than to continually seek input directly from stakeholders while building. The ideal plan drifts further and further from an evolving reality. Since shame is directly connected to failings of the ideal self, Waterfall projects are perfectly set up for shameful patterns.
This is why bringing Agile patterns to government can be met with so much resistance and why their successful application can be so transformative. The existing patterns of managing high risk are ingrained at literally a cellular level because shame operates at that level of primary biological affect. Shame shapes the fundamental story the organization tells itself. Like the shame experience itself, organizations can feel stuck and powerless. The way out is with trust and empathy, and those are the traits and patterns that Agile encourages us to build, through Agile’s insistence on smaller, less risky changes.
When I see a digital service team helping to transform how government manages risk, the pattern I observe is a group of people learning to negotiate with shame and shame culture. That’s why I often say that the hardest work in government IT is the emotional labor. When I see success, outcomes often include not just stronger systems but stronger teams.