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

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 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

“This meeting should’ve been an email.” But what about the meetings that needed an email? I can’t count the number of times I’ve participated in a meeting where the meeting happens and… that’s it. That’s the deliverable. No agenda. No recap. No action items. No record that the meeting happened other than a calendar block and, maybe, a recording no one will ever watch, or a transcript someone might dig through later, trying to find what could’ve been documented from the outset