For City Innovators: Process Before Platforms
Standardize the work, assign ownership, build accountability and then pick the tech.
The work of innovation in cities is not to buy new software; it’s to say “not yet” until we fix the work. Under pressure to be “smart”, governments reach for automation like a reflex. But digitizing a broken process doesn’t help residents; it just hides the cracks behind a login screen. Innovation begins with a deeper look at the problem, a redesigned workflow, disciplined data standards, ownership and accountability. Technology comes much later as a tool to innovate the improved process.
When I joined the City of Green Bay to drive innovation, I kept thinking about what innovation means for a city. It is such a broad term that any form of improvement can be listed under it. The initial conversations with the senior leadership informed me about the common pain points also in very broad terms like inefficient, archaic or slow. This is good information but does not really speak to the problem - solving which can be termed as ‘innovation’.
As I started meeting the staff members, since innovation was in my position title people would talk about innovation in their departments. Interestingly, most of the times, they will point to a new software system, an AI chatbot, or an online form and declare it innovation as it uses some algorithm to automate some part of the process. Which is not wrong completely. These are all new ways of doing things as most people would explain.
I remember my first conversation with one of our inspection supervisors and how he explained that automating the permit payment process will solve everything for the city. His passion really spoke to the size of the problem and his own struggle in the process. As all other staff members, he understands the process meticulously and told me all the possible solutions we can implement. As the conversation unfolded, I started asking more questions picking one solution at a time. After a few rounds of conversations we both realized that we don’t know enough. He at the end said we should automate the payment process.
And these meetings continued. Another meeting with another office was about automating the process of licensing, another one about automating report generation, another about automating meeting minutes, automating the curb side bulk waste gate system and automating fleet management…. this continues.. All these could be completely true as possible outcomes for the individual jobs but are we really talking about the problem? I don’t know. I restricted myself to taking notes and keep going back to them as often as I can.
After a month of these conversations, I started asking a few questions which mostly started with ‘what will it solve?’ and then a series of questions trying to drive the conversation where both of us can challenge each other’s assumptions. These questions are frustrating to anyone who does that job daily and believes that this is the best they can do in all the given constraints.
The other pattern was to highlight a new software tool that the department has onboarded for a part of the process. The question I would follow up with in this case would be - what did it change? 9/10 times the conversation would end as a blame on sales person who over promised and under delivered. This one was easier to deal with.
As a reflection of many of these conversations, I realized that public servants work in a split-screen reality. At home, we glide through voice assistants, automatic bill payments, one-click checkout, and online verification processes. At City Hall, too much still runs on paper, manual checks, and hand written forms. Over both hangs a third constraint: tight budgets and stretched human resource. And to me, these three together i.e. consumer expectations, legacy processes and limited capacity define the challenge and the opportunity of “innovation” in city government.
There is immense pressure on governments to innovate especially cities as they are the most familiar face of the state. Our staff engages with people on daily basis. Our staff members live among the same people we are serving. And under this pressure to ‘modernize,’ automation seems to be the best quick fix. Other thing we also overlook is that each city hall is also a historic place which has built its culture over time. The reason I am highlighting this is because innovation can not overlook these historical traces whereas modernization can. Innovation will have to account for this to see what needs to be preserved of that culture.
Therefore, innovation in cities can’t be achieved by simply layering algorithms over bad processes or by viewing technology as a magic wand. There is a need for indepth inquiry about workflows, processes, ownership, knowledge sharing, data processes to get some understanding of the problem. Lack of data, and information siloes further limits the potential to understand the problem. So more often, the data analysis tools will come to use much later.
This conflation of innovation with automation or digitization is not only simplistic – it’s dangerous. It can lead to “technological solutionism,” where each tool onboarding becomes another sales presentation with limited understanding of the impact on processes or outcomes. In my experience so far, most of the software onboarding has a metaphorical success which creates the appearance of progress, and when results don’t show up, there’s a vendor/software to blame.
I will give you an example: recently, I was tasked with a responsibility to create a motor pool and look into our fleet management system. This was supposed to be a simple side project which we thought will not take more than a few weeks especially with an intern joining the team. As a preparation to take up the project I reached out to the concerned staff members, held a few meetings and also gathered some data to prepare the plan of action.
The initial meetings highlighted two different software used by fleet managers and risk management team which takes care of the insurance premiums. I was given a detailed run through of both the software to figure out details about our fleet. Our objective was to figure out a motor pool and set up a system where these resources can be shared.
Since we need to set up a system for fleet we want to ensure that we figure out the least used cars and other fleet equipment which can be shared across departments. The initial analysis helped us understand that the datasets are not coherent at all. We started visiting all the shops, meeting mechanics, shop managers and fleet managers. As we started sitting with them to understand and learn more about their job, we found almost 5 software systems being used to store fleet data. Along with all these systems, each person who is part of the process also has an excel sheet.
We started collecting data from all these sources to put together a master sheet of the entire fleet data. Now each department has their own way of coding the data, storing the data, updating the data etc. The whole exercise of cleaning the data and verification processes led to a collective understanding of mistakes as we also use to meet collectively a few times. In this process, we removed assets of about 11M USD of the capital assets we don’t own anymore. Savings would be in recurring insurance premiums of each year to the city.
This whole problem had nothing to do with those software, it is to do with the lack of ownership, SOP and accountability in the system. Before we think about onboarding technologies, we will have to build all the three things.
Cut to the final presentation, insurance team suggested another software ‘origami’ (an upgrade in the current insurance software) that would solve the problem in the future and blamed the current mistakes on Faster which is another fleet management software program.
The simple answer to the suggestion is ‘No’. These software are built with an assumption that they would be fed with good quality data and would be timely updated. If we are faulting on the assumption, it is going to fail. Innovation here would mean doing all of this to make sure we don’t fail on that assumption.
All of this has become even more important to highlight as AI has become the new buzz word and will soon become a new ‘scapegoat’. Tech entrepreneurs and staff are mentioning AI as a potential solution in a lot of discussions. And hardly anybody is asking a question - what is AI without good data?
Imagine if we would have fed all the data we had collected in our fleet process understanding, any analytical tool would have hallucinated. It took us a few weeks of just sitting with all the individuals to catch those errors.
Let us just work together to build a consensus that Technology is a tool… As soon as we begin to think of it in that way, then it’s much more about the application of it in our context, than it is about just using the thing because everybody else is doing it.
I am writing to argue the same for city governments what Michael Hammer argued for private firms when computer came - “don’t automate, obliterate”. Rather than layering software on top of inefficient workflows, city governments need to radically redesign their processes, build capacity and accountable structures for improvement.
Over the last one year, I have learnt a few things about innovation:
Innovation has to be problem-driven, not tool-driven. Understand the problem and than look for a tool. Technology could be the tool or part of many of tools that are needed. It begins with recognizing that the current system, process, or service is failing in some way. Investigate in depth, keep asking questions, engage horizontally and vertically to make sure you have multiple perspectives. Give time to people for owning up the process and mistakes. Create space of trust to make sure that you really understand the problem.
A needs assessment provides the evidence. Instead of relying on assumptions, do systematic assessments (surveys, data analysis, stakeholder feedback) to reveal gaps between what exists and what is needed. Use all the conversations as data points and gather evidence to figure out systemic failures. Distinguish symptoms from root causes and share whatever you are finding.
Innovation fills the gap(s). The purpose of innovating is not novelty for novelty’s sake, but to address that shortfall in a meaningful, sustainable way. Continue the processes which are working well and focus on gaps at least to start with.
It’s time for city executives, innovation and tech teams to revisit what they mean by “innovation.” If the term is merely a glossy label slapped onto any new software procurement or automation project, it loses meaning. This has the potential of risking credibility, resources and trust on initiatives that don’t deliver real improvements. True innovation in city government is to demands critical self-assessment of needs, thoughtful process reengineering, diligence in data management, and continual communication and learning. It might not generate the same headlines as announcing a new procurement, but the results would really improve the base line.
Innovation isn’t the number of tools we buy; it’s the value our staff members and residents feel. Start with the problem, redesign the work, set the data standards, then pick the smartest tool that fits. Measure the results in days saved, errors avoided, and trust earned. That’s the kind of innovation worth announcing.