Many organizational problems aren't people problems. They're systems problems. The challenge is that "systems problem" isn't a diagnosis. So where do you start? When I'm trying to understand why a process isn't working, I don't start with solutions. I start with questions. Who owns the process? Can anyone see where work is sitting? Where does work change hands? Is the process documented? How do people report problems, and what happens after they do? None of those questions

Shared inboxes are a great place to start asking questions. Who decides what's urgent? How is work assigned? What happens when two people assume the other is handling it? What happens when no one responds? How do you know whether a message is being worked on, or just sitting? Does using the inbox require additional flagging, categorization, or workarounds that create more problems than they solve? Shared inboxes are often an easy solution to a problem that wasn't fully diagno

We've all run into situations where an organization decides on a solution before fully diagnosing the problem. Not surprisingly, it doesn't work. One of the biggest conclusions I see organizations jump to is staffing. It's a natural progression: something fails, everyone is overwhelmed, so the answer must be more people. But that's rarely my first conclusion. Before hiring, restructuring, retraining, or, above all, buying new software, it's essential to understand how the wor

Eleven is a design failure. We count: Ten. Eleven. Twelve. Thirteen... Then suddenly: Twenty-one. Twenty-two. Twenty-three. If we were inventing English today, would anyone create "eleven" and "twelve" on purpose? Probably not. And don’t even get me started on French. Quatre-vingt-dix. OMG STOP. It should be TENTY-ONE. Not eleven. TENTY-TWO. Not twelve. TENTY-THREE. Not thirteen. I know I sound like Lewis Black, but I’ll happily die on this hill. It’s not really about numbers

I accidentally made my best friend move to Columbus, OH. Not directly. She had narrowed her list to Philadelphia, Denver, and Portland. She had good reasons for all three, but I wasn’t convinced she was evaluating the places themselves. I thought she was weighing the idea of these places too heavily. I don’t mind being wrong. I mind making big decisions for reasons that weren’t fully examined. So I built a spreadsheet. Because of course. I researched ~50 cities that seemed to

One of the reasons I love small municipal government is that innovation and necessity are often the same thing. Large organizations can sometimes compensate for a weak process with additional staff, consultants, software, or funding. Small governments rarely have that luxury. When a process breaks, people have to think. When a resource isn't available, people have to improvise. When a resident needs help, the problem can't simply be handed off to another department. The work

Want to know whether a policy will actually work? Ask whether a town of 2,000 people can realistically execute it. One of the biggest misconceptions about small government is that it operates like large government, just on a smaller scale. It doesn't. Small municipalities are often expected to comply with the same regulations, reporting requirements, transparency obligations, election laws, procurement rules, and administrative mandates as much larger jurisdictions. The probl

Yesterday, I wrote about one of the fastest ways to predict implementation problems: ask who was missing from the planning. New Jersey's 2024 OPRA changes are a great example. Commercial vs. Private Requests Intent: Provide agencies with more time and revenue from requests serving a commercial purpose rather than the public interest. Challenge: Agencies now have multiple timelines governing records requests. In well-staffed agencies, that may be manageable. For lone Records O

One of the fastest ways to predict implementation problems is to ask a simple question: who was missing from the planning? We frequently see scenarios where implementation challenges are treated as secondary concerns instead of core design questions. Policy doesn't exist in a vacuum. In many municipalities, there is no legal department, records team, project manager, or operational buffer. There may be one clerk managing elections, public notices, records requests, governing

Most exclusion doesn’t announce itself. It appears as: Forms that assume everyone has the same background knowledge. Office hours that require someone to miss work. Websites that only function on a desktop computer. Public notices written in language that large portions of the community can’t understand. Meetings held in locations that residents can’t access. Hiring processes that reward people who already know the unwritten rules. These are often treated as inconveniences, b

People who design processes tend to focus on what happens inside the organization, but the public experiences what happens outside it. A delayed response feels like indifference. An unclear process is exclusion. Repeated requests for the same information feel like incompetence. Conflicting instructions feel like nobody is in charge. Most system failures don’t look like system failures to the people affected by them. They look personal. Someone assumes they are being ignored.

People experience government through systems long before they experience it through politics or policy. Most residents never interact with an organizational chart, strategic plan, budget document, or legislative agenda. They interact with a form, a website, a permit application, a records request, a utility bill, a phone tree, an inspection process, a missed notification, or a confusing instruction. For most residents, the system is the government. When I was a Village Clerk,

Ok Chicken Littles, this one’s for you. Fast decisions are not always good decisions. Treating everything as an emergency means nothing is an emergency. Your emergency does not become someone else’s emergency because you say so. People need timeline context to triage appropriately. No: "Need alpaca thing ASAP!!!!!!!!!!!" Good: “I need the alpaca project wrapped up by 5pm tomorrow.” Better: “Can the alpaca project be wrapped up by 5pm tomorrow?” Best: "This is urgent because i

We love the myth of spontaneous collaboration. A brilliant idea > A quick meeting > Everyone jumps in > Magic happens. Except that's usually not what happens. Good outcomes rarely happen by accident. They happen because someone thought about the process. Collaboration without preparation is interruption. It might be important interruption. But it IS interruption. And spontaneous collaboration is really just unplanned work. Now someone has to: Context switch > Stop current wor

Instead of job interviews asking “How do you manage competing priorities?” maybe they should ask your opinion on unexpected Teams calls. "you free?" That depends. Nobody is actually free. What do you need? How urgent is it? How long will it take? Am I the right person? Do I need information before we talk? Can this be handled asynchronously? It takes 2 seconds to say "Are you free? I need feedback on XYZ." And that tiny adjustment provides essential context. The second versio

A 60-minute meeting recording is not a meeting summary. A transcript is not a procedure. A Teams recording is not a training resource. And "it's in the recording somewhere" is not a documentation strategy. Many of us have probably found ourselves digging through old recordings (or *ahem* 36,910 screenshots) trying to answer what should have been a simple question. The information technically existed. Somewhere. In a recording. Maybe in a transcript. Possibly in a Teams chat.

Organizations make a huge mistaken when they treat project management and operations as separate disciplines. They're not. They're siblings, not neighbors. People always talk about project management and operations as though they're completely different functions with completely different goals. Projects launch things. Operations maintain things. Projects create change. Operations create stability. Projects are temporary. Operations are ongoing. All of that is true, but it's

If everything is project management, what happens when the project succeeds? It becomes operations. At some point, someone decided to implement a new system, launch a new service, create a new policy, establish a new process, or solve a problem. And while they’re working on that, it’s a project. It has: Meetings Timelines Milestones Status updates People are actively thinking about it. And if you're good at your job (especially the risk mitigation part), the project succeeds.

The longer I work (and it is feeling REALLY long lately), the more convinced I am that everything is project management. I know some PM traditionalists are going to come at me for it, but I said what I said. The impact doesn’t matter. The complexity doesn’t matter. The scale doesn’t matter. The budget doesn’t matter. The audience doesn’t matter. The industry doesn’t matter. If it has a start, a plan, deliverables, and a close, it’s a project. Of course building critical infra

Organizations often invest in new tools to fix existing problems. Sometimes the tools help. Sometimes they expose what’s already broken. When workflows are unclear, ownership is inconsistent, or standards vary across teams, new technology tends to amplify those issues instead of solving them. I’ve seen this happen with records systems, intake processes, and internal tracking tools. The system works as designed, but the underlying process was never clearly defined. Better outc