Category: government (Page 1 of 2)

In May 2022 I decided it was time to take a break from government service. I had been working with and in governments since 2015 and I was tired. I had the privilege and luxury to change jobs and start working in the climate change mitigation problem space.

Below is the spiel I gave my co-workers at Truss on my last day. Truss was a tremendous place to work and if you’re interested in the kinds of technical and organizational challenges that are their speciality, I recommend you give them a look.

I’ve duplicated the spiel text directly, so a few notes. One, Truss employees refer to themselves as Trussels. Two, Truss is a fully distributed company and so all the weekly all-hands meetings, or what they call “Prac” (short for Practioners’ meeting), are all on Zoom and most company communication happens via Slack. Three, there’s some salty language, and you may lose some of the affect in reading it versus hearing it. So just try to imagine my serene, Midwestern, public-radio-like, dulcet tones if you can.

If you have small people with you on this zoom call, you might want to mute the audio or put on headphones because I’m about to use some adult language.

There have been a few old timer Trussels who have left the company in the last few months. One of the things I’ve heard them say is they miss how the Truss culture has changed. I am not one of them. I know that culture is always an artifact of who is present, and when a company grows as quickly as Truss has, there’s no way that the culture would remain the same. One thing I have noticed, though, as perhaps a bellwether of that cultural change, is the relative decline of the word “fuck” in Prac meetings. Maybe it’s a subtle self-censorship, as if with so many new people we’re trying to practice a little more polite company etiquette. Maybe not. Certainly we’re living in unprecedented times, so my anecdata is exactly that. In any case, if you’re one of those who bemoan the loss of Truss culture, don’t worry. In the next 3 minutes I’m going to significantly raise the average number of utterances of the word “fuck” dropped during Prac.

I’m going to drop a visual aid into the #prac channel.

I’ve always thought that the word “fuck” is a little like the word “smurf” in that it can mean anything you want it to, entirely dependent on the tone and context in which you use it. If you’re offended by the word “fuck” I completely understand. I was raised in a conservative evangelical family and until I was in middle school, I thought the “f-word” was “fart.” Even to this day, I feel more squeamish saying “fart” aloud than I do saying “fuck” aloud. So now I’ve said both words aloud in a single sentence, and yes, even at age 50, I can confirm that the strange-ness persists.

My own need for therapy aside, I’d like to share my thoughts on two phrases with you on this, my last day at Truss. My dearest hope is that you will hear what I have to say and then actively resist and even reject it. Hopefully you’ll see what I mean by the end.

The first phrase is “give a fuck.” Or its inflammable counterpart, “don’t give a fuck.” I say “inflammable” because “give a fuck” and “don’t give a fuck” seem like opposites but can mean the same thing depending on how you say them, much the way that “flammable” and “inflammable” appear to be opposites but actually mean the same thing. To “give a fuck” means to strongly care about something. But if someone says, in an emotionally strong tone of voice, that they don’t give a fuck, then I suspect they actually do give a fuck. There’s a corollary: “fucks to give” as in “I’ve run out of fucks to give.” And of course, the old chestnut, “what the fuck” which is what you say when you give a fuck but wish you didn’t. I could go on. We have a funny language.

I like people who give a fuck. I feel a certain comradery with them, even if the things they give a fuck about are different than the things I give a fuck about. I have a hard time understanding people who don’t give a fuck about anything. Usually I suspect they are just in the closet about what they give a fuck about, and are afraid of disappointment. That’s what cynicism is: the fear of appearing to give a fuck. As we know, cynics are disappointed idealists. And if there’s anyone who really gives a fuck, it’s an idealist.

I mention giving a fuck and not giving a fuck because of a second phrase I’d like to introduce you to: civic chill. This is a phrase I made up to describe a particular kind of being in the world. Have you ever met another human, especially an older person, like an activist or social worker or community organizer, who seems to both give a fuck and not give a fuck, simultaneously? Like, they are ready to march in the streets, get up in the face of the powerful, agitate and advocate for what needs to be changed, and yet they seem totally chill, relaxed and trusting at the same time? That’s what I mean by civic chill. It’s a passionately detached engagement. It’s the simultaneous embodiment of believing that what you are doing and saying really matter in a crucially important way, and that they are also doomed to fail. It’s a paradoxical tension in the best Kierkegaardian sense.

Some of you know where I’m going with this. And some of you are googling Kierkegaardian.

The kind of work Truss does in and with governments may require a great deal of civic chill. Or not. Whenever you start a project, the odds are not in your favor that you will ever ship something to production. Most often, failure to ship is not a technical problem and most often it is completely out of your control. It’s one of the many tech-in-government problems that are not about technology but are instead about compliance and procurement and budgets and organizational inertia. If you manage to ship, great! Celebrate! If you fail to ship, recognize that there are many forces aligned against you and it’s likely not your fault.

So you have to start each day holding two contradictory beliefs: what you are doing really matters, and likely it will fail and not matter.

Even though I have, temporarily (I hope), currently lost my civic chill, I am still going to share with you my secret for how I keep it when I’m able to. The secret is: give a fuck, really give it. Then give it away. And then celebrate the privilege and opportunity to give a fuck. What a gift.

Alright my friends. I wish for you the freedom to both give a fuck, and not; to dwell in your civic chill, and not; to make good coffee, and not. Peace.

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.

There’s an old joke that the hardest problem in programming is naming things. We rarely talk about why. I suggest it’s because naming things is the crucial point of contact between our two audiences. We write code for both people and machines. Machines don’t care about naming except that it be consistent. People, on the other hand, want words to signify to realities outside the code itself. The next programmer to read my code is my audience too, and I need my word choices to signify to their nuanced and lived understanding of the problem we are trying to solve with the code. This is one example of why I have often said that computers are easy and people are hard.

I’ve spent the last five years of my professional life in and around governments. One of the results of that time has been a lot of thinking about the words my colleagues and I use to describe the work we do. So far, the least bad words we’ve found are “Digital Service.” We are not satisfied with those words, because they still confuse some people that we work with. Still, they are accurate, and until we find something better, we’ll probably stick with them. Here’s how I define them.

Digital Service (initial cap, singular, not services) is a specific form of public (government) service designed to bring people with skills and experience with modern information technology from the private sector into the public sector for limited lengths of time. The two goals are modernizing the way government services are designed and delivered, and exposing a particular talent pool to the experience of public service. Digital Service is an idea similar to the Peace Corps or AmeriCorps.

I rigorously avoid the phrase “digital services” because it confuses folks who, when they hear the words “digital” or “technology” immediately place it in the mental category of the nerds/geeks down in the basement who you call when your printer won’t print or your computer won’t start. That’s digital services. Some of those nerds may leave the basement and join a Digital Service and day-to-day use the same skills, but their efforts are directed in a different strategic way.

Because Digital Service is not really about technology. It’s about changing organizational process.

The Digital Service mindset says: governments should begin with understanding what their constituents need and want, and deliver those services in the most constituent-friendly way possible. If constituents needed and wanted tax forms delivered to them on stone tablets, then the Digital Service approach would be to (a) identify that need and (b) work with other public servants to deliver it in the best way that they can. The word “Digital” describes the field in which these public servants have honed their skills, not necessarily the means by which they serve.

Now of course it just so happens that most constituents prefer mobile electronic devices over stone tablets, so it’s quite convenient that those same people committed to meeting constituent needs also happen to be fluent in digital technology.

The problems we encounter in government are the same human problems we encounter everywhere, only more so. The difference is that government impact is at such a bigger scale and with an institutional memory and inertia much greater than other organizations. Because of that bigger scale, there is a lot of fear in government. Government is full of risk averse people, just like other large organizations. Large organizations, in fact, attract risk averse employees, because they are stable places of employment. The consequence of all that risk aversion, however, is that things rarely change. Digital technology changes rapidly in the private sector. The public sector, resistant to change, full of fear, is slow to change. And yet government constituents need and want services built with modern technologies, which governments are very slow to adopt. That tension between what government is suited to provide and what its constituents want provided has led to debacles and lots of time/money wasted.

Enter Digital Service. Why is it that people who have spent time in the private sector working with modern technologies would have skills in managing large institutional change? The truth is that we don’t. What we have is experience working in ways that allow for managing risk. The biggest systemic problems we have encountered in government are not about technology per se. They include:

• acquiring the necessary paperwork to launch a new website (ATO)
• hiring people
• how the government buys technology (procurement)
• managing custom software projects

None of those are technical problems. They are all risk management problems. Like the old joke about naming things, we address them with Digital Service because Recovery From Risk Avoidance Service is a mouthful.