0.0 Context Setting

It's Tuesday, 7 March 2023. I started writing this on Friday and then got waylaid. At the time, we'd mostly extricated ourselves from the just over 10 inches worth of snow that fell in just under 12 hours the week before.

One long, single topic thing this time.

1.0 Some Things That Caught My Attention

1.1 Good Enough

For the last few weeks I've been working with The Century Foundation and Philadelphia Legal Assistance as a consulting technologist for their Unemployment Insurance Modernization project.

TCF put out a report in 2020¹ on the state of unemployment insurance system modernization across U.S. states and if you're reading this, you can probably fill in most of the conclusions: the systems aren't great, and modernizations aren't going great either. The report, from October 2020, came out around the (a) peak of ongoing the COVID-19 pandemic², before vaccinations were widely available, but also after the massive country-wide surge in unemployment claims.

It also won't surprise you that

[the] single strongest recommendation in this report is for states to place their customers at the center of a modernization project, from start to finish. The biggest mistake states made was failing to involve their customers—workers and employers—at critical junctures in the modernization process.

There are so many reasons as to why this doesn't happen, but for now I'm going to consider as out of scope the fact that unemployment insurance systems are often not politically designed or implemented in a way to actually deliver employment insurance to people who are owed it and need it.

So! As a consulting technologist, my broad job is to help the TCF and PLA team help advocates be more effective in holding to account those responsible for the technology delivering unemployment insurance.

I've been along to a bunch onboarding meetings and getting-to-know-you meetings that, in effect, have been pretty unstructured user research sessions to help me get the lay of the land. Here's what caught my attention.

Most products, and therefore their vendors, are terrible

... but we knew this already. Yes, I know we can easily distribute responsibility and blame if we want to, but in many cases, vendors appear to be coming to the table with significantly deficient products.

In some cases, some vendors are so terrible as to have had their executives federally indicted and caused the cancellation of entire procurements! ³ I'll come back to more examples of how products are terrible.

Most states or government customers don't feel they have a choice

In general, if most products are terrible and most vendors are therefore terrible and it's generally true that in states thanks to decades of outsourcing the ability to effectively manage a critical technology program has pretty much withered away to a vestigial remnant of capability, the only way to even conceive of developing and delivering unemployment insurance and its required technology is to outsource the entire thing to a vendor, then... of course, you're going to need to do that. Then a cycle begins, like I've written about before, of doubling down on project management and trying even harder than ever before to nail down those pesky requirements so you can do a better job than last time.

In a way, most states or government customers don't really have a choice if they don't choose to do something different. I realize this is effectively saying the same thing as above, but yes: your degrees of freedom are exactly the same if you do nothing. You would have to do something else.

The problem then lies in a combination of not knowing what else to do, and then actively choosing not to do something else due to a bunch of reasons, most of which involve a fear of failure. Which is reasonable: most of us don't like or enjoy failing, and for many people the experience of failure is more commonly than not experienced in terms of guilt, shame or punishment.

Advocates aren't able to clearly express the shortcomings of a system

I've seen this time and time again: in systems like these, workers, customers, users, whomever has a job that requires them to interact with that system likely has at the least a sense that things could be better.

Another way of putting this is:

Advocates are unsure of what they should expect

I wouldn't go so far as to call this gaslighting. This is, broadly how the situation presents:

• Advocates are well aware that unemployment insurance programs are complex and that implementation varies significantly from state to state
• Advocates are well aware that unemployment insurance systems are also very old, or also have a very long history
• Advocates experience a slow pace of change in the technology implementing a program: everything from a department saying they can't hit the implementation date of legislation because their system isn't ready, to years upon years of a lack of availability of multi-lingual access, again, despite that multi-lingual access being required by both state and federal legislation. This slow pace of change also includes "updating a form on a screen".
• Advocates experience inflexibility in a system: either being told that systems flat out can't do certain things, or that, as above, certain things can be done, but they are very hard or that they are way down a list of other things to do.

This unease and sense that thing should be better has only gotten worse with the change in consumer technology over the last thirty-odd years.

Now, if you're going to spend tens (or even hundreds) of millions of dollars on a transactional technology system of which an utterly unsurprising fact and therefore requirement is that the legislative environment will change and that program rules will change, then by definition you need a flexible system, but flexibility itself isn't enough.

I've looked at responses to requests for proposals and vendors get asked questions like:

• can we customize the product to do x?
• can the product be modified to do y?
• does the product support doing z?

And every single time the answer is "yes" because of course the answer is going to be yes. It's software. At the end of the day, you can say anything is possible, provided you wait long enough and/or you spend enough money.

What's missing is how long does it take to do x, which to be fair is also a difficult question to answer because as I pointed out above, in the U.S., the entire philosophical approach to government is that states, broadly, are allowed to do whatever the hell they want, even when it's not in their best interest.

One particular horrific example of inflexibility that, again, is partly a result of a customer not doing due diligence, is a story about a customer not wanting a particular part of a workflow, but that workflow was baked in to the system they bought. So: customizable. A bit. But not really.

A lack of understanding means a lack of clarity, lack of clarity means a lack of identifying responsibility

There's another title for this section, which is Here's What's Reasonable To Expect of Software In 2023.

Here's an example:

• Departments are required by legislation to support workflows in multiple languages
• Departments have already done most of this work, because the workflows and content exists as a baseline in paper form, or can be accomplished through some sort of horrifically tortuous IVR system
• Departments also, as a backstop, know how to do this because at the very end of the day, you can talk to an actual human, if you are prepared to wait long enough

So let's be clear: the program capability is there, and has been there.

Now we can talk about the software. Systems from vendors make a number of representations about language/multi-lingual support, like:

"we implemented features that enhances our client’s ability to load translations into the system to improve the overall solution’s multi-lingual capabilities."

and

"implemented architecture for multilingual support (2011)"

and

"Multilingual framework (2016)"

and

"The solution also has been enhanced to implement multi-lingual correspondence focusing on providing equitable access to wider group of customers."

and

"Ability to support multiple languages in FAST software, correspondence and e-Services (2008)"

and

"language table decode length improvements (2015)"⁴

and so on.

And yet, I've consistently heard from advocates that they've been told that systems "cannot support multiple languages" or that there isn't the ability for a workflow to have another language option.

But this isn't acceptable.

It is not reasonable to accept this.

It is not reasonable to accept this is partly because the concept of globalization, internationalization and localization for support for different languages has been around for decades.

The example I've given to advocates is that enough of them are old enough to remember that in the 90s, you could easily switch Windows into Spanish. All of it. It would work. In Spanish. And the same for Microsoft Office. And not just Spanish. French. German. Lots of other languages. Yes, right-to-left languages took longer. But, you know, these days modern software supports unicode emoji out of the box or box-cloud.

The clear example is that an advocate should be able to hold up their phone in front of someone telling them that this is too hard or that their software doesn't support it yet and just toggle the entire system between English to Mandarin to Spanish to Japanese to French to Polish to Romanian. And it's easy.

The reason is that when you're building modern software these days when it's an upfront requirement that you support multiple languages there are established ways of doing so, and that saying that "it's hard" isn't an excuse. It isn't impossible, it's just more work and of course it's going to be more work, you're implementing more than one language. Duh. You at the very least have to provide translation of all the text.

So now we have a bit more clarity and we can ask some more questions:

• How trivial is it to implement an entire workflow in Spanish?
• Or Romanian?
• Or any other language, from this list?
• How much time should it take?
• What's involved?
• Who needs to do it?

Because now advocates can tease apart responsibility, for example:

• purchasing governments should know it's reasonable to expect, in 2023, localization frameworks and for it to not be a software issue to add additional languages
• vendors should be offering products that, given localization frameworks and their purported usage of content management systems, allow customers to easily update content in different languages themselves
• departments are responsible for providing workflow-specific custom language translations
• vendors may be expected to come to the table with standard workflow language translations
• nobody gets to demo without at least one alternate language pathway

Let me be clear: there is no technology reason for a lack of language support.

Now, vendors might come back with "well, it's complicated given you're dealing with modernization all the way back to ye olde mainframe system", but then I say the ball is back in government's court.

The requirement is multiple language support. So you need to receive bids with multiple language support.

Another quick example is "how long should it take to update a word on a screen and for it to appear in production", to which there is no acceptable answer other than "within 24 hours".

Again, this is an opportunity to understand the difference between "technology" and "process" and not just say, for example, "we can't update the website that quickly", which does a honking brilliant job of obscuring responsibility and accountability for all the different steps along the process.

Again, the reasonable expectation is that there should be no technical reason why a content update like changing a word should take more than 24 hours to show up live for everyone.

That said, possible reasons could be:

• our departmental change request process and risk management process requires at least n people to sign off on any change to the system
• our departmental change request process and risk management process meets every n days to sign off on any changes to the system
• or any changes must be prioritized, and the prioritization process only happens at the beginning of every sprint
• any change requests are handled through the vendor or state-specified change request system which may range from anything like "writing a memo in a Word document that's attached to an email and is then re-entered in an Excel spreadsheet saved in an arbitrary location on Sharepoint" to "writing a tortuous Jira ticket"
• department users are not allowed to change content themselves
• the vendor's change control process requires n people to sign off on the change on the vendor side

... which helps everyone figure out exactly where which parts of latency lie.

Boundaries

This has been very long, so I'm going to finish with one thing I worked out: it's not the job of advocates to deal with all of this. Sure, employment departments need to get better at actually managing the technology they use to do their job. Technology departments need to do a better job of managing discovery, design, development, delivery and ongoing everything for services. Finance departments need to figure out new ways of budgeting for and, well, financing critical software infrastructure for government services. Legislators and representatives need to know how to hold government to account.

So at the very least, the thing that I've worked out is that advocates need to be able to speak clearly and constructively about the issues they see, and then be able to hand off to other organizations or entities. It's not their job to educate a department about what product or service management is and why it needs to be a thing. Like I said, that's the department's job to go find out. Advocates can, I think, go so far as saying "well, you should go look here and talk to these people", but their role again can (should?) stay in the "it should be at least this good, why isn't it?" box.

I suppose, then, there's the boundary of not my circus, not my monkeys, and then being able to set a boundary of expectations of performance.

Whew! A lot. And a while since the last one.

How have you been doing?

Best,

Dan

How you can support Things That Caught My Attention

Things That Caught My Attention is a free newsletter, and if you like it and find it useful, please consider becoming a paid supporter, at pay-what-you want.

Do you have an expense account or a training/research materials budget? Let your boss pay, at $25/month, or $270/year, $35/month, or $380/year, or $50/month, or $500/year.

Paid supporters get a free copy of Things That Caught My Attention, Volume 1, collecting the best essays from the first 50 episodes, and free subscribers get a 20% discount.