Hacker News Reader

Comment by ccleve | Hacker News Reader

Well-written article, useful insights, total misunderstanding of the way things like this should be done.

There's an old saying: don't pave cow paths. That's exactly what he was doing. He was putting a different front end on an existing process. You end up with a total nightmare.

Instead, this should be done department-by-department, app-by-app. Design the process from the bottom up. For example: a form to request some document. Start with the documents: how are they stored? Should they be stored differently? Are they in a database? Should we really even be storing documents, or should they just be database entries? For that matter, should the department that manages them even exist? (Here in Chicago, the answer was no. They merged the County Recorder of Deeds office with the County Clerk.)

You should never just move things online. The web is different, and enables different business processes. Change the process first. Forms come later.

View on HN

You're not technically wrong, but what you are suggesting simply doesn't work in government. Each department is a kingdom with varying amounts of political clout. Only the smallest and least-powerful groups will jump on board with a mandate that induces invasive and drastic changes to their workflows. The kingdoms with more political clout will laugh in your face and slow your progress down until your project simply runs out of clock time. The result is that you still have all the same legacy workflows and also this new workflow for the small number of groups you had more power over.

This guy managed to achieve his mandate AND managed to entice groups to investigate updating their workflows after the fact. I agree it's not the way things SHOULD work, but he managed to find a way to make the most amount of progress and along the way some kingdoms were enticed to cycle back around and improve their workflows too.

Great point. With the Federal Govt that often breaks down to "agencies that use GSA as a service provider" and "agencies that roll their own."

In DC their in house 'innovation team' tried to overcome some of these issues and make them more useful to the people using the forms by having an annual formapalooza. Results were mixed but it is an interesting approach to digitization and human centered design.

https://thelabprojects.dc.gov/formapalooza

I haven't done a lot of work in government, but I have done a lot of work in orgs with distributed power structures, and this is 100% correct. Starting from the ground up means constructing a working group for every single workflow in which everyone who is even theoretically a stakeholder (and many people who aren't) is going to demand to be in the room and be heard. Once you get past 4-5 people, good luck holding a meeting more than once every few months, and if a single powerful stakeholder doesn't like what you are doing or perceives that you are stripping them of power, they will gum up the process until it fails. I've had 4-5 value adding initiatives crushed in this manner at past jobs.

IMO, the optimal strategy in such an environment is to get at least one powerful champion on your side who can give you political cover, and then to quietly construct a MVP while soliciting feedback from high performing rank and file in the departments of interest who you know (ie no other power brokers besides your champion(s)). If you can deploy a value adding MVP it becomes difficult for antagonists to intervene and kill the project without appearing petty, and then you can really get to work building the product you want.

I sort of imagine some departments opting for a webform-to-fax gateway :)

Except what he did resulted in progress.

What you are proposing most of the time will not because it would require an immense, truly Herculean, amount of political will and backing.

Redesigning processes clashes with the #1 rule of big systems: processes are ruled by people whose jobs depend on them. And they WILL fight tooth and nail to keep those jobs. The bigger the change, the more threatened they will feel, the more they will sabotage you.

And you know what the #2 rule of big systems is: no matter what "the boss" may say, if the officials are not on board it's just not going to happen.

If you have not, I suggest watching "Yes minister" :).

People don't like to be told they have to change the way they do things because... the computer.

Years ago, I was at a very small company that used Exchange. We had some outages and it was just a lot of administrative overhead in a world in which Gmail was by then an option.

But one person in particular fought the change strongly because they were used to a business/sales process that used hierarchical folders to keep documents organized and Gmail, at the time, only had single level labels. The CEO mandated the change anyway but the other person never accepted that Gmail was suitable for our needs.

Sure. But also, lets admit that software developers are not qualified to redesign processes of institutions they dont understand, so fighting them is pretty often rational from institutional point of view.

If the processes of an institution can't be explained to a real, qualified software engineer, the issue runs much deeper than just resisting to change.

The author was given the mandate to "move forms online", so they chose the quickest, most agile option and did just that - moved forms online.

The author later brings up the questions you mentioned - what is a form, should these forms exist, etc, but instead of spending a long time trying to design an entire new system _when that wasn't even asked of them_ they decided to deliver results. Once they gained trust and got buy-in by the city, they could think bigger.

> Instead, this should be done department-by-department, app-by-app. Design the process from the bottom up."

Sounds great. If you can do this in less than a week for each form (the author managed 100 forms in 2 years) then you're perfecting processes _and_ moving them online faster than the author.

But just in case you missed it, let me quote a couple of bits of the article:

"Getting city workers to accept online submissions rather than traditional paper ones is the bulk of this work. On average, it took me about 30 minutes to make a digital form and five weeks to meet with, earn the trust of, and get buy-in from the employees who would use it. Even if they were excited, the nitty gritty details took a lot of back and forth."

"Some departments had sort-of insane business processes for submissions. If I tried to change those, I would spend a whole year on a single department. By focusing on the priority, moving forms online and making it easier for the customer, I could make consistent progress rather than be consistently blocked."

My guess is that you're going to spend decades perfecting processes, only to find the world has changed (or the politicians in control of the City of Boston have changed the law that governs the processes!) by the time you're ready to begin digitize forms. You're letting perfect be the enemy of good.

> You should never just move things online. The web is different, and enables different business processes. Change the process first. Forms come later.

Sometimes "just moving things online" is a big improvement over the status quo. But the author agrees with you in at least one case. See the paragraph about what they are doing about death certificate requests.

Yeah, I agree. A lot of what I deal with at my job is similar. The people doing the work just don't want people coming in telling them new ways to do things. It doesn't help that vendors are constantly promising the sky and leaving them with broken things. But once you start showing them small incremental improvements they start to discover the next step etc. Then they see how machines can help them and make suggestions.

In my field there's a very well-known example of a MRI manufacturer who has made very "smart" systems that end-users simply refuse to use. Technologists know how to operate a scanner, when a machine starts trying to help them it's very difficult for them to (1) understand what the machine is doing and how to work with it and (2) trust the machine, primarily because physicians yell at people, not machines. There are maybe 10-20% of the technologists that "get it" and want to tinker and learn how to use the new features. The rest still miss the way scanners worked 20 years ago--because they understood and trust them.

That's the thing with paper forms--people can understand what's happening, discover the process and figure out how to succeed and not to be yelled at. When it disappears into a machine it might as well be a blind and deaf new hire who keeps messing with your desk. It's a major issue of trust.

So the parent's "no it needs to be this giant reinvention when strangers who don't do the work come in and tell you that you need to do everything differently" attitude maybe works with management.

I honestly think the big problem here is that we don't seem to have systems that people can play with to build their own ideas anymore. Maybe sharepoint but my god I can't even figure out how to do anything on that. It really boggles my mind that we have things like iPads and iPhones but nothing like Hypercard.

This approach is likely to produce better experiences if it could be seen through to the end, but also likely to go nowhere inside a large organization.

Change is hard. Radical change, all at once inside a big organization is near impossible.

In this case, it’s a great first step to get all this info out of paper and wooden inboxes and into a more accessible form.

Doing so still leaves open the potential for reinventing high-priority forms and workflows. It also makes it easier, because now the team can easily ask questions like, “how many people use this?” And “how much time do we spend on this?” Etc.

In short, while you might be right wrt. producing innovation, sometimes the first step is to just put it on the internet.

Change needs to come from the top. The UK did it with Gov.UK, and their success inspired many other governments around the world to follow them.

And how long did it take?

I think Gov.UK was (and is) great, but it's entirely possible that doing a lift and shift of the paper based forms might have gotten more done in a shorter time.

This is 100% correct. I run a govtech startup (similar to Seamless docs, the company mentioned in the article), and this was one of the key insights we've picked up over the last couple years.

When your process happens on paper, there's nothing forcing you to ensure it makes logical sense. You can draw whatever you want on a piece of paper, so a lot of the paper forms that people call "permits" are just messy reflections of the thought process of the person who originally conceived the process. Naturally, products that start by directly replicating a paper form are accommodating and perpetuating the lack of planning.

We've kind of taken a backwards approach where we don't accommodate direct translation of forms and instead provide tools that encourage people to think through the steps of their permitting processes to get them to make sense on a digital platform. More often than not, they discover glaring inefficiencies in the process which when fixed make everything work more smoothly even independent of the move to a digital platform.

Shameless plug: https://citygro.ws

I will disagree. In the distant past, we had a bunch of forms to move online and our platform was SharePoint. I know, I know, but before you blame SharePoint, we didn't get to the point of SharePoint being the issue.

Instead, we got endless bikeshedding about "the process" and during that, many unrealistic expectations were conjured into existence as each process was re-imagined into kind of ultimate, abstract form of near infinite configurability. Try to imagine sitting at a table as someone says, with complete seriousness, that people ought to be able to submit a multiple one terabyte (not mega or giga, tera) files with a particular webform. Not any other transfer protocol, either. And this is back around 2008 or so. It should just ... expand as necessary.

Nor was this the only time I encountered this kind of behavior. I have seen functionaries whose visions of process suddenly bloat like that "elephant's toothpaste" when presented with technological options. I would do the forms first, given the chance.

That saying is strange because cow paths usually represent the most direct path somewhere that the designer of the space failed to imagine.

Is this picture a bad thing? https://i.redd.it/uj5ehfdxn5o31.jpg

Those aren't cow paths, those are people paths. Cows are not known for their tendency to walk in straight lines. Edit: notice they still had to put up fencing to keep people from cutting off even that minimal switchback.

This might be a dialect issue. Where I'm from, "cow path" is the normal way of saying what also called a "desire path" by others. According to the wikipedia, I'm not completely out to lunch: https://en.wikipedia.org/wiki/Desire_path

I hadn't heard "cow path" before, but a quick google suggested it was a synonym for "desire path" so I went with that.

It is a strange saying. My guess is this is something that's lost in translation—a leaky metaphore—and the people using it don't think about real cow paths.

Real world space is (generally) 2 dimensional, and these cow paths are often very predictable and sensible. They're usually the result of architects thinking that sometimes people actually walk or bike, instead of always driving cars.

In the world of bureaucracy & information tech, the space can be very convoluted, and shortcuts aren't really the same kind of thing (queue XKCD comic on spacebar heating).

Cows tend to pass where other cows passed. Herd behaviour. Something like a real world effort optimisation.

No use trying to optimise in a week using one brain something that found a local minima (or maxima) over years and multiple people.

Normally the change (and effort) to achieve a better minima (or maxima) has to made on a variable you just can't see or imagine.

Something on the line of Chesterton’s Fence.

That saying is also oddly appropriate here because the joke for anyone who lived in boston is that the city is built on paved-over cow paths.

(yes yes fun-police, it's actually a myth https://www.bostonmagazine.com/news/2018/03/06/boston-street... but the truth of it being a bunch of ad-hoc cities that coalesced into one entity isn't too far off from the truth. My favorite bit of Boston artwork is road silhouettes of all the Boston-area squares: http://andywoodruff.com/blog/boston-squared/ )

> Design the process from the bottom up

Bottom up IT system reimplementations fail much more often than incremental ones.

Bottom up reimplementations of operating human systems that also involve big bang IT implementations are even worse, by comparison to incremental evolutions, mixing incremental automation with incremental process improvement.

And it usually only takes one high-profile failure of a big-bang implementation to derail a broad reimplementation process, whereas the occasional incremental setback on an incremental improvement process is rarely politically significant to the overall process.

So, no, I disagree with your recommendation that this should instead have been done with a more waterfall-style approach.

The argument in the article for gradual change sounded reasonable to me. Just moving a process online is at least a first step.

> Some departments had sort-of insane business processes for submissions. If I tried to change those, I would spend a whole year on a single department. By focusing on the priority, moving forms online and making it easier for the customer, I could make consistent progress rather than be consistently blocked.

Re: should they just be database entries? he did do this or make other changes when the department agreed.

Except to redesign the processes you need buy in and co-operation from multiple different people and departments and good enough project management and communication with all of them to ensure that the thing you replace the forms with will actually do the same job.

Whereas moving existing forms online in the same structure can be done with minimal management agreement and provides a quick win.

Especially when you're talking about 344 forms. Redesigning all the back office processes for 344 forms would be a gargantuan task.

> Instead, this should be done department-by-department, app-by-app. Design the process from the bottom up.

It is a technical way. "Do not mind people, just make tech to work". This way have its benefits, like it tends to make result to have better design, but what about people? They work and they think that their work is important and valued. But "hey, some engineer came and started to make it his way without any reverences to us". It is humiliating, and such engineer could face a resistance.

The author made a genius' move which I might expect from a psychologist or any other social oriented person, not from tech-savvy engineer: he started to make life of a people better. He asked their opinion on how they think it would be made better. He showed respect. He showed people that he sees them as people, not as gears in a clockwork mechanism. They reacted as people generally tend to react to this: they welcomed him. Probably it helped that it was government bureaucracy which likely treat people as gears in a clockwork, so his way of treating people contrasted nicely to the way they used to.

I have expertise in the space and while I would have agreed with you 10 years ago, I disagree today.

There are billion dollar programs that can be replaced by a Google Form. You’re always going to lose if you are too accommodating. Every one of these dopey workflows has a unit of FTEs on payroll in the backend!

Get High level sponsorship, hard deadline and most things will be doable within reasonable constraints. The stuff that isn’t doable is the hard work, which you will never discover until it’s forced.

Great idea! I wonder why nobody has ever thought about that before! You must be the first! A modern day Prometheus!

The highlighted part about the fact that it takes 30 minutes to make a change, and FIVE WEEKS to get sign-off is spot on. I fucking hate bureaucracy. But you know what happens if you don't take the FIVE WEEKS to get sign-off? Nothing.

> For that matter, should the department that manages them even exist?

Yeah, nothing better then complete reorganization by someone who has no idea about the work being done, needs and pressures.

What will happen here is that they will quickly realize you dont know what you are doing but are threat, so whoever will have option will easily stall you.

Wasn’t one of the the points of the article the complete opposite of this comment? You can improve the process without having to overhaul the whole thing. They don’t need to flip their tech stack for forms.

It seems more like a classic case of refactoring except that the original infrastructure is paper-based, in which case the ideal digital redesign would be one that mimics the paper-based one precisely so that "regression testing" can be performed and components can be swapped in piecewise. Once enough components are digitized, the system as a whole can begin to be molded into more effective forms. This would have to be the plan at the outset, since it would require preserving enough flexibility.

> Change the process first. Forms come later.

In government that can easily mean the forms coming never.

That's just as true for the corporate world. Check out the business processes of, say, a global telecom that's been around since the era of party lines. SAP SE makes buckets of money from big corporations that just want computerized file cabinets.

> There's an old saying: don't pave cow paths

Not said by any dairy farmer. If you believe this, you never shovelled cowshit. Believe me, dairy cow paths and pens are paved, for a reason.

Pave cow paths, but start at the dairy and work backwards.

A lot of government agencies lack the budgeting required to go through a process of "as-is" and "to-be". This process is both lengthy and costly and is usually reserved for the main portion of that agencies workload.

Workflows and form-related processes are a little like desire paths, true. Over time people establish ways of working that define the business logic of a company. Some of it is codified on paper, some in the culture and interactions, and it all tends to slowly change over time.

There is a lot of value in the existing processes. That's what the business is built on. Proposing to drastically change how things work while promising that the result will be at least as good or better -- that's a tough sell for a lot of reasons. It also seems incredibly risky, projects like that are no easy feat.

I think a gradual, incremental approach would have a higher chance of adoption and eventual success. Small asks that produce tangible improvements, building towards a systemic changeover.

Did you try to do something like that - moving a government office into digital world? What is your personal experience with this?

> ...the way things like this should be done.

Do you have case studies for successful process reengineering efforts?

Your misunderstanding of how things work in government is at least as egregious as the author's misunderstanding of this idealized way to redesign processes.

Do you see any middle ground between the 'rebuild everything from the ground up' and 'rework the user interface' type approaches?

Didn't he specifically address this, in the section where he brought up "salami slicing"?

I'd love to read more about this view. Do you know any good books about this subject (government digitalisation)?

The iceberg image at the top of the article fails to show how much of an actual iceberg is beneath the surface.

Reply on news.ycombinator.com