Recent Insights.

"Let's ask someone first" usually isn't about getting better information. It's about not wanting to be the one who's wrong if it doesn't work. That's a completely human instinct, and it's expensive. The organizations that move fastest aren't the ones with the least oversight. They're the ones where a small, reversible decision doesn't require the same process as a large, permanent one. Not every fix needs a committee. Most don't.

Things that should probably not require a full board vote, especially for nonprofits we work with. × Fixing a broken donation link × Updating a program description × Changing which staff member handles first-reply emails × Adding an accessibility improvement × Approving a template you already reuse for every newsletter × Automating a thank-you email that currently gets typed by hand Boards exist to govern strategy, budget, and risk. Routine website maintenance isn't any of those things, and treating it like it is slows down exactly the kind of small, low-risk fixes that should never wait a full quarter. What's on your website right now waiting for a meeting that doesn't need to happen?

What have you been sitting on because you weren't sure you were "allowed" to just do it? Not a big, risky decision. Something small. A fix, a page, a message you've drafted three times and never sent because it felt like it needed someone else's blessing first. Reply if you're willing to name it. We'll go first in the comments.

A client once had a routine task stuck for six weeks, not because it was hard, but because nobody was sure whose job it was to approve it. Everyone agreed on what needed to happen. It sat in an email thread getting acknowledged and re-forwarded, because no process had ever named an owner for that particular handoff. Once we asked, directly, who was actually accountable for it, the task closed out in a day. We see this constantly in workflow work. The fix is rarely the hard part. Deciding who's actually responsible for making the call usually is.

Things that should probably not require bringing in an outside consultant. × Renaming a shared folder so people can actually find things in it × Assigning a clear owner to a task everyone's been quietly avoiding × Turning a five-step email chain into a two-step form × Setting up an automatic reminder for a deadline that keeps slipping × Documenting a process that currently lives in one person's head × Deciding who signs off on routine expenses under $500 Some workflow problems genuinely need outside eyes, especially anything touching multiple systems or real automation logic. But most of what keeps a small team stuck is a decision nobody's made, not a tool nobody has. What's the process at your organization that everyone complains about but nobody actually owns?

Most organizations aren't held back by a skills gap. They're held back by a permission gap. Somebody on the team is fully capable of updating that page, fixing that workflow, or making that vendor call. What's actually stopping them is waiting for someone else to say it's okay, even when no one ever told them they needed to ask. Shows up constantly, on websites, in day-to-day operations, and in who's actually allowed to manage a vendor relationship. Rarely about competence. About who feels entitled to just decide. This month is about naming the specific places that shows up, across websites, workflows, and team decision-making.

Things that should probably not require calling an outside IT consultant. × Adding an email address to a shared inbox × Updating a password policy × Setting up an out-of-office reply × Adding a new employee to your calendar and file access × Renewing a domain name × Turning on two-factor authentication Some of this genuinely does need a specialist, especially anything touching security or infrastructure at scale. But a lot of it doesn't, and treating every technical task as equally scary is how organizations end up either avoiding all of it or paying for help they don't need. Starting next week, we're spending October on a version of this question for the rest of your operation. What's something at your organization everyone assumes needs an expert, that actually doesn't?

An organization that posts constantly for three weeks around a launch and then goes quiet for two months isn't building a presence. It's broadcasting. To an audience, silence doesn't read as neutral. It reads as "they've moved on" or "things must have slowed down." Neither is usually true, but perception doesn't check. We'd rather see an organization post two unremarkable things a month, every month, than one impressive burst followed by silence. Steady beats loud, almost every time. Curious if anyone disagrees with that trade.

Genuine question, not a rhetorical one: are you using AI to move faster on things you already know how to do, or are you using it to skip deciding what you actually want to say? We see a real difference between those two uses. One speeds up good strategy. The other produces a lot of confident-sounding content built on a foundation nobody actually agreed on. Which one is closer to how your team is using it right now?

A client told us, "nothing's really broken, we just feel stuck." That sentence describes more organizations than actual, visible breakage does. The website loads. Nobody's complaining. Inquiries come in at a trickle that feels survivable. It doesn't feel broken. It just isn't getting better, and it hasn't been for a while. That's usually more expensive than a visible problem, because nobody ever decides to fix something that isn't technically failing. Sat with that one for a while after the call ended.

Unpopular opinion, maybe: if you're a small organization with limited time, social media should be the last channel you invest in, not the first. Your website is the only thing you actually own. Your email list is the second most valuable thing you own. Social platforms rent you an audience and can change the rules on that rent whenever they want. We still think social matters. We just think most small teams have the order backwards, and it costs them. What do you think?

Things that should probably not require a full website rebuild. × Confusing navigation × A homepage that buries what you actually do × Outdated language about a service you changed two years ago × Inconsistent messaging between pages × A slow-loading image gallery nobody asked for × One really bad form A rebuild is sometimes the right call. But most of what's actually wrong with a website lives in a handful of specific pages and decisions, not the whole structure. Tearing it all down and starting over is often the expensive way to avoid fixing the two things that matter. What's the one page on your site that's actually the problem?