• bigger-better-CAcert

• česky | english

A general strategy for rehabbing a nonprofit in a state like CACert's

• Notes for CACert

• By Susan Sons

Start with re-evaluating the mission

An organization that exists without a compelling mission is at best ineffective and at worst harmful. Here's the trap that CACert seems to have fallen into, as described by Peter Drucker in Managing the Non-Profit Organization:

Non-profits are prone to become inward-looking. People are so convinced that they are doing the right thing, and are so committed to their cause, that they see the institution as an end in itself. But that's a bureaucracy. Soon people in the organization no longer ask: Does it service our mission? They ask: Does it fit our rules? And that not only inhibits performance, it destroys vision and dedication.

When CACert set its mission all those years ago, like a bunch of engineers (working with FOSS nonprofits is why I've seen this so often) they focused on the details of what they were going to do rather than the reason they were coming together to do something. The world has shifted under your feet in the mean time and, listening to the CACert people I have met, they are still focused on the mechanism you all started with, rather than looking for ways that this incredible group of dedicated and talented people can make a difference in the world, as it stands today.

Good To Great lays out a fantastic framework for figuring out how to make a good organization into a great one. Part of that is what Collins calls the "Hedgehog Concept": the intersection of What you are deeply passionate about What you can be the best in the world at, and What drives your economic engine (in the nonprofit context, this is what you can get donors and volunteers behind, and how you can demonstrate your effectiveness to them).

If I were guiding CACert through this, I would start with a lot of "why"s... Why do you want to sign certificates? Why <that last answer>? and so on. Somewhere under all that, I think you will find a shared dedication to open access to technology, a believe that trust networks are important, a belief in lowering the effort and expense involved in individuals being able to secure the things that are important to them, and much more. That is what you build a mission from.

Once you have a mission, you then have to sell it. If you aren't all moving in the same direction, you can't be a healthy and productive organization. That means selling all the major stakeholders you plat to keep--board members, donors, and volunteers--on this mission.

Write down a plan

What will you do next? Who will do it? This next phase is hard, because engineers will bikeshed you to death if no one is wrangling them effectively.

The goal is to have a plan of action, at a very high, very general level, that enables decision-making over the course of the next year or two. You'll need to cover:

• What you will keep doing, and an "owner" for each activity or project who is responsible for making it work.
• What you will stop doing, again with an owner for each, and how you will responsibly phase out those activities.
• What you will start doing, again with owners. This will usually take some more work than the first two. That's the nature of doing something you haven't done before.

Don't worry about planning everything out in detail. What you really need to know is:

• Who owns each activity?
• What resources does this activity need, and how are we getting/providing them? "Resources" includes not just the obvious money, servers, storage, etc. but also people and skills.
• What is the expected time line of the activity?
• What are a handful of milestones along the way?
• How do we know if this activity is on track or off the rails?
• How will we measure success?
• How will we check in and decide if the plan needs to change, if more resources are needed, or if the project needs to be abandoned, etc?

You'll need to think both about 1-5 activities (don't overdo it! be a hedgehog!) that serve your mission. You'll also need to think about the functions that make a nonprofit work: fundraising, finding and onboarding volunteers, managing volunteers, accounting/paperwork, and having someone keeping an eye on strategy so you adapt to the world as it changes.

How to use a straw man document to get agreement on your plan of action

It's going to be tough to get engineers through this. It always is. One approach that has worked for me in the past is the same way the U.S. Constitution was ultimately written. Have 1-2 intelligent and dedicated people go off in a corner alone to write a "straw man" strategy document. Rather than letting a big group squabble over a blank page, give them something pre-written so they have to propose specific edits to get their point across. It doesn't even have to be that good, it just has to get everyone away from the blank page. Steps to introduce a straw-man document:

1. Let everyone know that this is going to happen. Tell them that you will send out a straw man document X days before the meeting on $date, and that they will be expected to have read it and be ready to ask questions at that meeting. Remind them that the straw man document is just that--a placeholder, something to start with--and that everything is open to discussion and change. The goal is for everyone to edit this placeholder together as a way to come to an agreement.
2. Go write your straw man and deliver it on time, preferably in a format like a Gdoc that makes it easy for many authors to contribute while tracking who made what suggestion. Give editors "Suggest and Comment" permission so you can accept/deny specific edits following discussion.
3. At the meeting, walk through questions and comments on the document and discuss each one. Let people know when you will circulate the next draft.
4. People who don't engage and comment or question don't get a say. If someone doesn't have the time or inclination that's fine, but don't let anyone veto the whole process just by ignoring it.
5. Expect to go through 2-5 drafts before you have a final, depending on how much your group is on the same page when you start. Using this writing process in the future will go faster, because most will have had a chance to get used to it.

Build the systems that will enable the work

This part is easier for engineer types. You need to build systems as you go. Systems can include:

• Software
• Documentation
• Habits / processes
• Other tools

What you will need will depend a lot on your plan of action, but here are some random examples from my past:

• Set up a ticketing system so that the sysadmins have a shared space to deal with requests
• Write an onboarding checklist that we can use for each new volunteer to ensure that they are put on the right mailing lists, get the right login accounts, are told the right information, etc.
• Set up a CRM to keep track of our donors and communicate with them effectively.
• Teach 1-2 key members of each team how to run a meeting efficiently and effectively so we can have fewer, shorter meetings and get more done.
• Set up a group chat or email list or ClickUp/Asana/Basecamp/etc project for each project team so they can communicate easily.
• Set aside a monthly or quarterly meeting for leadership to receive updates on each project or activity. Is it meeting milestones? Have changes needed to be made since the last update? What successes and challenges has this thing faced?

When you do this, make sure to prevent bikeshedding and premature optimization--traps that attract engineers like sugar attracts flies. I advise also that no system is allowed to exist unless there is a set date to re-evaluate and change/improve it.

In most of my projects, we do that step monthly for something we consider experimental and yearly for most things considered stable. Though, sometimes it makes sense to trigger a review when you use the system, like updating/improving the onboarding checklist each time you finish onboarding a new volunteer.

Get hold of your altitude

...by which I mean, know when you need a 10k foot view, and when you need to be down in the weeds looking at minutia. Engineers are prone, generally, to being too far down in the weeds most of the time, but individuals vary.

Having ~3 people in your org who are looking after the big picture so no one else has to is a huge win. I love the triad of a people leader, a tech leader, and an up-and-comer, which we discussed on the phone. It's small and flexible enough that small nonprofits can manage it. It also gives the up-and-comer a chance to grow and learn in case they someday must replace one of the other two.

If those 3 or so people can learn the mechanics, for lack of a better term, of having an organization, then they can pass down to others just what those others need to do their part. It takes a huge load off. We can't ask an org full of engineers to stop acting like engineers (not gonna happen). We can get a small group together than begins practicing the other types of thinking the organization needs, so all bases are covered both on the engineering side and on the having-an-organization side.

=== I hope that helps. I'm here for questions ===

Resources that may be useful

Good To Great by Jim Collins

• This book is fantastic for finding what can really make your organization successful, what Collins calls your "hedgehog concept".
• There's also another version of this book titled something like "Good to Great for the Social Sectors" which is said to focus on the needs of nonprofits. However, since I've never read that one I thought better to recommend the original.

Managing the Non-Profit Organization by Peter Drucker

• Drucker is probably the best-known writer on business and organizational strategy, and for good reason. His work has lasted through the ages and is mostly good sense. This book covers a lot of the pitfalls to avoid, but also a lot on keeping people moving in the same direction and ensuring it's the right direction.

Manager Tools by Mark Horstman, Mike Auzenne, Sarah Sentes, and Kate Braun

• I love pretty much everything this company produces. My average for a business book is about one useful idea per book. I get dozens from each MT book I read, let alone the podcasts and events.

• Start with the free podcasts, especially the Basics Feed or with the book The Effective Manager (Second Edition). Then dive into everything else.

• Part of the struggle with small nonprofits--especially those operated by engineers and programmers--is that when it's nobody's day job, often no one will take on the role of manager. So, no one is really responsible for getting everyone moving in the same direction, for coaching volunteers, for setting a strategy, for putting in place things like quality control and donor management. Volunteers need feedback and coaching and personal attention. Somebody at CACert needs to be prepared to act like a manager of people when needed, or you won't have a successful volunteer program.

• CategoryCAcertInc