Future Here Now: when experience hurts more than it helps
Coming attractions
This piece is a segment from my upcoming book, Don’t Screw Up Your Program: A practical guide for nonprofits, agencies and foundations that don’t want to be miserable.
I’ve been around long enough to have seen all sorts of awful program design and administration, from little nonprofits to state and national organizations. And after a particularly bad experience last year, I started to put together this book to give a super-practical guide to …basically not being miserable, for yourself or the people your program is supposed to help. It’s very direct, very conversational, occasionally tongue in cheeck and not pulling any punches. It’s the kind of real-world guidance that I want for anyone who finds themselves running a program.
This section not only gives you a taste of the book, but it digs into one of the other ramifications of that hierarchy to network/hive transition that we saw in the Signals from yesterday. In a hive, important information and insight doesn’t just come from someone higher up the food chain, or someone with more years of experience in something kind of similar to what we’re facing.
I wrote about this years ago in The Local Economy Revolution Has Arrived: the expert’s job has changed from Proclaimer of Truth to guide through the forest of alternatives. And the person who has decades of experience in the category might actually be too locked into an accustomed way of doing things to provide the guidance relevance to your challenge.
It’s especially important to include the people that you are designing the program for in the work of designing the program. That’s especially true if those people have been done to, not with, by your organization and others. Which is usually what we’ve done. And pro tip: if the people you are designing the program for aren’t currently getting paid for helping to craft programs, then pay them. Compensate them for their time, their effort, their expertise, for helping you. Don’t expect them to volunteer because it will be “so good for your community!!!!” That’s not fair to them, or to the community you claim you’re trying to help. And it increasingly reinforces that community’s sense of being disregarded or used.
This section from Don’t Screw Up Your Program also includes a worksheet for evaluating how important experience and other factors should be to your selection of partners. The following section has a worksheet that helps the reader frame out their selection criteria, which is critical to making the right decisions. The book is full of worksheets and excercises to help break down unseen assumptions and increase the odds of getting the results people want. The newsletter format doesn’t let it look as neat as it does in the book, but hopefully you get the idea.
If your program’s purpose (as you defined it in Part 1) means that you need other people's expertise, this section [of the invitation to participate] is where you learn about what they know how to do.
In theory.
If your program is a continuation of a long-established process, where all the standard expectations will hold true, then you're looking for someone who has done the same exact thing a whole bunch of times. The more the better.
But if you're trying to solve a problem that old approaches haven't fixed, or you're trying to create something new, then the kind of someone who was great for the program in the last paragraph might be a truly terrible fit for yours, Maybe even damaging.
Why?
Innovating is a different skill set from applying a high level of established wisdom. And someone who is an expert, totally comfortable doing something based on the fact that they have done things like this many times before, may end up so locked into conventional approaches that they can't think of anything new.
Expertise can be like being inside a box for a long time -- you might know exactly where everything is inside the box, but you may have no clue how to deal with the world outside its walls.
If your program is intended to do anything new, you need to ask for more than the usual glossy project descriptions and resumes. You may need to ask specifically: Tell us about a time when you created an innovation, created something new or a big improvement. Tell us about a time when something didn’t work and you have to find an alternative route.
You might find that the most established providers with the fanciest projects and the fattest resumes and 8,000 years of combined experience aren't who you want to work with, because there's nothing to indicate that they can get out of their box.
Worksheet: what kind of qualifications do you want?
Size of team
Big <------------------------------------------------------------> Small
Experience in field
Deep (exactly this kind of thing lots of times before) <----------------------------> Broad (experience with a lot of different approaches)
Ability/Willingness to innovate
Set process <—------------------------------------------->Willingness to try something new
Level of communication with me
Constant<—--------------------------------------------------------------->Infrequent
Level of collaboration
High <—-------------------------------------------------------------------->Low
What else?
One end________________<—---------------------------------->_________The other end
One end________________<------------------------------------->_________The other end