This is related to the Show Don't Persuade
principle, and it's
about not stressing everyone out (especially yourself) about the process
Sure, there's a bunch of ideals
we're presenting in this knowledge base - great ways to help the
outcomes be most beneficial to your the whole network. They're based on
experience, and core network principles, and important systems thinking
insights. And ultimately, you do want to evolve your project into using
all these great ideas. But the fact is, this whole field is still very
emergent and there's no point in freaking people out with more process
than they're able to deal with and imposing too many should's (on the
group, or on the mapping team). It's also helpful to trust in your
people's and your own capacity for learning.
In other words - treat it as a learning journey, not as an engineering blueprint to follow to a T.
like with Show Don't Persuade
- in a classic SNA, the idea is that you
have to push for a high percentage of responses or the whole thing is a
complete waste of time and money. Deadlines often get extended because
there isn't enough data. And survey/connection questions & options
can get word-smithed to death, because there's no going back. Once those
choices are made, you're stuck with them until next year (and -
honestly, with the cost and the work involved, and the limited payoff -
how many 'next years' actually happen?). It takes a long time to prepare
and there's a lot riding on getting it right.
the fact is, until people are familiar with an interactive Social
System Map, they really don't have a deep enough understanding of what's
possible to craft great questions/options anyway - they're not ready to
'get it right' and you telling them what 'right' is doesn't help them
learn it for themselves. You telling them keeps them looking to you for
the answers, when the whole point is to enable them to see and act from
this new way of understanding on their own.
not let it evolve over time? Why not do what they can imagine right now
so they stay interested, sense-make and reflect on what you end up
with, draw out suggestions for improvement and trust that - as they
engage with it, they'll better understand what's useful and what's not.
They'll tell you what should be changed so it will be more useful to
In other words - I never argue, or
pressure a group to use a particular approach or to see what I see. If
they make a decision I think is dumb, I let them (with the exception of
technical decisions that will make BIG messes that will take a long time
to fix). If I make a suggestion that other clients have benefited from
and they reject it out of hand, I let them.
don't get me wrong - I do push back - just in case - but gently and
briefly. If they're not ready to budge, or if it's controversial enough
to cause tension among them, I don't see the value in letting everything
get stuck in that particular debate. I surrender lightly because a) I
trust it will all get worked out in the end, and b) there's plenty of
other things to deal with in this moment, and c) it's possible they see
something I don't. I could be wrong and lose out on an opportunity to
I assume it's all a
matter of when, not if. If the process step, question, idea, message is
right and necessary - it's time will come. If not, there's no point in
wasting time trying to force the issue.
the map is made, they'll see for themselves why a decision was dumb, or
why what I suggested was a good idea - and that kind of learning (for
themselves, not handed down by me when the whole thing is still pretty
abstract to them).
Meet them where they're at. Do what they can imagine doing. Trust in emergence and iterations. And reflect, reflect, reflect.
Read about the other principles.