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

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

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.

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