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

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

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

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

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

One of the most common operational issues I see isn't complexity. It's unclear ownership. A task gets shared across teams. Responsibility gets assumed, questions get redirected, and deadlines slip. Everyone is involved. No one is accountable. I’ve seen this in policy implementation, internal workflows, and public-facing work. A request comes in, touches three departments, and no one is clearly responsible for seeing it through to completion. Clear ownership doesn't mean doing

Access isn't just a policy value. It's also an operational outcome. People experience access through practical details: Can they find information? Can they get an appointment? Can they understand the process? Can they complete forms? Can they reach a person? Can they get help without starting over? Mission-driven organizations often talk about access in broad terms, but access usually breaks down in specific places. A practical starting point is to map the user journey from t

When organizations feel pressure, one of the first instincts is to add people. Sometimes that is exactly right. But frequently the problem only looks like staffing. If workflows are unclear, ownership is fuzzy, tools are outdated, and priorities shift daily, adding headcount will only increase confusion. I’ve seen teams grow without improving outcomes because the underlying process never changed. A practical step before hiring is to map the work: where it starts, where it slo

I’ve worked in government, nonprofit, and private-sector environments, and I’ve noticed something consistent. Most organizations have the same core problems. Unclear ownership. Weak process. Poor communication. Misaligned incentives. Too much urgency and not enough planning. The language changes by sector, but the underlying issues are usually the same. A policy initiative stalls in government. A nonprofit program struggles to grow. A private-sector project misses deadlines.

Modernization is not enough. Redesign is the next step. For years, improvement has often meant layering new technology onto existing systems. That approach can deliver incremental gains, but it is starting to hit its limits. What’s emerging now is something different: a shift toward rethinking how work actually happens. Not just new tools, but: how decisions are made how workflows are structured how teams are organized how data is shared how learning is built into operations

There’s a difference between a transition question and ongoing reliance. A quick follow-up a week or two after someone leaves is normal. It happens. But when an organization is still calling months later, something else is going on. That’s not about helpfulness or professionalism. It’s about missing infrastructure. If knowledge lives in one person’s head instead of in systems, documentation, and clear handoffs, the work doesn’t transfer. It follows the person out the door. At

Mission-driven organizations are often asked to solve complex problems while operating with thin staffing, aging systems, and constant funding pressure. Passion is essential, but it isn't enough. Strong nonprofits need infrastructure, too: sound governance, realistic staffing models, clear ownership, healthy finances, and practical systems that support the mission. Too often, administrative capacity is treated as overhead instead of impact-enabling infrastructure. The organiz

Many organizations think trust is built through messaging. It’s not. It’s built through operations. As more organizations experiment with AI in core workflows, the same question keeps coming up: can people trust the system? That question is not answered through branding. It is answered through performance. Do calls get returned? Are deadlines met? Are decisions explained? Are processes fair? Can people access what they need without unnecessary friction? When systems fail, peo