This is related to the Show Don't Persuade principle, and it's about not stressing everyone out (especially yourself) about the process too much.

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.

It's 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.

But 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.

Why 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 them.

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.

Ok, 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 learn something.

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.

Once 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).