an eddy in the bitstream

Category: government (Page 1 of 2)

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 congress.gov 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 openstates.org 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 OpenStates.org site itself will soon offer the same kind of functionality. When it does I’ll be glad to shut down legalerts.us and treat it as a learning exercise that helped me experience how a bill becomes a law.

How I Spent My Fall Vacation

In 2016 I could not have imagined I would come to know my way around the Kansas Statehouse, and yet two years later I was the one guiding my fellow members of the new governor’s transition team through the entry with the metal detectors and into the limestone catacombs. It’s funny how you find yourself places.

I am starting an accounting of what I was up to between Election Day 2016 and Inauguration Day 2019, and what I have learned the last few years as an accidental activist, things that went well and things that did not. A retrospective of one.

Election Day 2016

It would be too simple to say that the results of the 2016 American presidential election pushed me into politics. There were really a lot of factors that got me off the couch. But certainly I was angry and unmoored on Wednesday, November 9. Not because my candidate lost. My candidate wasn’t on the ballot. I gritted my teeth and voted Democratic on Tuesday, like a lot of people. I felt a lot like I did after the 2004 election. I was not enthusiastic about the Democratic candidate, but the Republican candidate was so obviously a poor choice that I just could not understand why so many of my fellow Americans voted for them. In this case, my primary fear was about the critical issue of the climate. We only get one planet, and science shows that the human species is pretty well screwing it up for ourselves and all the other species. The GOP candidate was going to ignore and belittle the science at a critical moment in history when decisive political action is needed by the world’s biggest economy and carbon producer. That was just unconscionable and unacceptable to me.

The Morning After

The first thing I did after Election Day was read a lot of the morning-after analysis and second-guessing. As an engineer, I was most interested in understanding the tactical and logistical reasons the election had ended the way it had, and what could be done to change the outcome next time. Setting aside the whole mess of presidential candidate narratives, and what campaigns and foreign governments did or failed to do, I took away a few things.

  • The maps are skewed. Republicans had systematically targeted state legislatures around the country, won control of many of them, and used the power of district boundary drawing after the 2010 census to gerrymander their way to control of the US House. It was really ingenious. Hats off to them for the strategy and the execution.
  • The state legislature is where the action is. Having wrestled away power at the state level, the Republican party was able to set the policy agenda and define the terms of political debate. Taxes, schools, roads, budgets, redistricting. This was very evident in Kansas where I live. Since the moment we moved here in 2013, my daily newspaper was filled with budget crises, Supreme Court suits over school funding, concealed carry gun rights expansion. All because the legislature and the governor’s office were controlled by conservative Republicans determined to starve the state government till it was small enough to drown in the bathtub.
  • The Democratic party, during the glamour years of the Obama administration, failed to invest in state and local parties, in campaign infrastructure, and in building a bench of local elected officials who could compete in federal races. School boards, county commissions, water boards, city councils: these local elected offices are where people learn the mechanics of campaigning and governing. Any professional sports fan knows most players don’t jump from high school to the pros. The senior teams develop and groom a pipeline of qualified players who can compete, and the best get promoted. The Democratic party had failed to do that.

I learned all that by reading: the New Yorker, the New York Times, the Atlantic, the Washington Post, the great raft of internet pundits, my local public library. We had recently acquired a new chair at my house, and I settled into what became known as my “nest” by our unlit fireplace, books and magazines stacked on the brick hearth.

I spent an unhealthy amount of time on Twitter. I created my first Facebook account so I could start to understand how people could be so affected by that product. I joined every email list for every nascent group committed to resisting the new administration. (I have since unsubscribed from nearly all of them.) And I got ready to get to work.

This is the first in a series of posts. The title of this one comes from one of my favorite songs. I didn’t want to be “just sitting at home, growing tenser with the times.”

« Older posts

© 2021 peknet

Theme by Anders NorenUp ↑