11 things I learned working in local government

For most of the last three years, I’ve had the privilege of launching and implementing the smart city program in Redlands, California. Now I’m leaving local government for The Atlas Marketplace , where I will help proven urban innovations — the kinds we implemented in Redlands — reach more cities, faster.

Here is part one of a list of 11 key things about smart cities I learned while building one from the inside:

1. Yes, cities are risk-averse

Two of the worst things that can happen for a city official is to 1) make a bad decision and have the consequences splashed all over local news and 2) unintentionally break a law and suffer major consequences. Avoiding these two worst things becomes a major incentive for anyone who works for a local government. Every step of the way, culture, systems and processes tell city employees “slow down, don’t screw up.” Given that there’s often a tremendous amount of money — and sometimes lives! — on the line, this is perfectly logical. Acknowledging the reasons for local government risk aversion can go a long way when trying to pursue something new in local government like a smart cities initiative. Bonus points if you’re able to figure out creative ways to “de-risk” a new technology or partnership arrangement for the city without slowing progress down.

2. Some silos exist for good reason

There’s a maxim in innovation that silos are bad, and cool things can’t be achieved without abolishing them. We’re always talking about breaking down silos , cutting across silos , opening up silos , sharing data between silos . But often silos exist for really good reasons. One consequence of city risk aversion is that analysis paralysis can be a huge problem. Everything has to be studied 10 different ways, more people always need to weigh in and even then, no one wants to make the call.

Silos can help sometimes. By assigning a topic to only one department or division, city leaders can more effectively build employee ownership of the topic. When someone owns a project, not only are they more likely to build the necessary expertise, but they’re also more motivated to make tough choices because they know they’ll own the failure of doing nothing.

3. Cities should focus on problems and outcomes, not solutions and tech

Too often, people focus on the new shiny thing in smart cities rather than the problem that the new shiny thing can help a city solve. The projects that get built and the tech that gets adopted all address pain points for citizens or pain points for government employees. What are the biggest problems in citizens’ daily lives? How can we improve the daily effectiveness and efficiency of our city employees? The solutions that scale are the ones with awesome, measurable outcomes: taxpayer dollars saved, hours of staff time that could be reallocated to other projects, number of road closures avoided, percentage decrease in traffic accidents, amount of time reduced from average commute, etc.

4. For vendors: engage at the right level (which is probably not the city council)

Please stop calling the city council with your sales pitches. It’s tempting, I know. It seems like they’re the final decision makers anyway. But it’s not that simple. In my experience, council members will listen politely, but then turn around and kick the idea down to a director, who will kick it down to a manager, who will assign the actual investigation to some staffer who already has a million things to do and little context for any of it. Now, instead of this being an investigation undertaken to solve concrete problems, the staffer who calls you back is merely checking boxes. You’ve likely already lost.

Instead, do your homework. Figure out what problem your tech solves, and who owns that problem. Engage with this person. They may actually care.

5. Don’t put lipstick on a pig

Whether you’re a city official tasked with building a smart city, or you’re an entrepreneur who’s developing the tech that makes a smart city possible, it’s easy to get caught up in the magic of extreme possibilities and forget about all the critical stuff that every government is built on. This is true of internal government processes: things like time sheets, email storage, shared file management, work order processing, land use tracking, rental inspections, and employee training tools all represent huge opportunities for improvement and must be in place before doing anything fancier.

But it’s also true of our built infrastructure: things like broadband access, a more flexible and resilient energy grid, and equitable transportation infrastructure are all prerequisites for pursuing sexier smart cities efforts as well. Perhaps the best example is basic cybersecurity, which is grossly overlooked all across the smart cities industry. It’s rarely sufficient to simply bolt new ideas onto the super broken substructures of existing organizations. Whatever the case, make sure you’ve included at least some of the basics in your smart city strategy, or you run the risk of burning out before you really get started.

6. Prioritize problem-solving over problem-reporting

In Redlands, we discovered that the single biggest complaint category on the city’s 311 app was reporting around burned out street lights. Our first instinct was to streamline the way alerts flowed through the responsible staff and to add a ‘response to citizen’ step into the process.  This is bolt-on innovation. It feels like progress, but the citizen experience hasn’t meaningfully improved. After thinking a bit deeper, we instead worked on digitizing street lights with internet-of-things devices that automatically detected when a bulb was close to blowing. Auto alerts could then be integrated into the maintenance workflow for field staff and bulbs preemptively replaced. Instead of incrementally improving the 311 experience (which ironically forces residents to think even more about frustrating issues), real innovation in this case meant solving the root problem.

Stay tuned into StateScoop next week, when we post the second half of this list, which includes discussion of open data, failed projects and the importance of patience.