an eddy in the bitstream

Category: government (Page 1 of 2)

Civic Chill

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.

KS SOS election results

The Kansas Secretary of State elections web page says that “precinct specific election results are available upon request.”

However, according to the statute:

“The secretary of state shall publish on the official secretary of state website results by precinct for all federal offices, statewide offices and for state legislative offices not later than 30 days after the final canvass of the primary election is complete.”

So it appears that the SOS office is not following the law.

Since the general election precinct results have a similar requirement to be published no later than 30 days after the final canvass, which must be held no later than December 1, I would expect general election precinct results to be available on the SOS website by December 30, 2020.

I hope that by then the SOS office will be following the law.

Update 2021-01-05 Happy to report that the 2020 general election results have been posted. The primary results still have not.

Shame, software, and government

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.

Digital Service is not about technology

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:

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.

Follow a Bill

After the election, reading was how I spent my free time in November and December of 2016. That, and talking to my brilliant partner about all I was learning about political machinery. As it happens, she is a professor who teaches social policy and takes her students on field trips to the state capital in Topeka. She suggested that if the state legislature was so important, I should learn how it actually works: find a bill and follow it through the legislative process.

So I went to the Kansas legislature website and tried to figure out how to follow a bill. I found I could search bill text and find bills if I knew their number, but I could not find a feature that would send me email whenever the status of the bill changed: when it was going to be discussed in committee, or voted on, etc. I knew from using the federal site that it was possible to get alerts on federal legislation emailed to me if I created an account. The same kind of follow-the-bill alerts feature did not seem to exist for the Kansas legislature.

I figured that someone must have solved this problem already. The closest I found was which did not have the alerts feature but did have an API that I could use. After touching base with the OpenStates developers to see if the alerts feature was planned (it was but without a timeline), I decided to see how quickly I could prototype the legislative alerts feature myself. A classic yak shaving exercise. I had three design goals:

  • The minimally viable product should take no more than a single weekend;
  • Send alert emails for a single bill or a saved search (like a Google alert);
  • Store the minimum amount of user account information possible.

Since I had been doing a lot of Ruby on Rails development for my day job, I decided to use that tool to meet goal number one. Goal number three was made possible thanks to the wonders of OAuth: I could let users log in using an existing account (Google, Twitter, GitHub, but not Facebook since I did not (yet) have a Facebook account). Goal number two proved to be the trickiest but that was where all the fun was. I found an existing Ruby client for the OpenStates API and after some experimentation, hit on a data model that did most of what I wanted. The end result seemed good enough to me that I decided to go ahead and register a domain name and set up a GitHub organization and a Twitter account. I figured I would use it, at least, and since it could search all US states, maybe others would find it useful.

What I did not know yet was what bill I should follow. This is what yak shaving can lead to: lots of energy spent working on the thing you think you need in order to do the thing you want to do, and then sort of forgetting about the thing that got you shaving that yak to begin with. (I did eventually find a bill to follow: my own.)

Each year since then I have updated the site to reflect changes to the OpenStates API and to make small improvements. But basically the site is as it was three years ago. It does one thing and it tries to do it well. I’m told that the site itself will soon offer the same kind of functionality. When it does I’ll be glad to shut down and treat it as a learning exercise that helped me experience how a bill becomes a law.

« Older posts

© 2024 peknet

Theme by Anders NorenUp ↑