Designing software and systems that are flexible, resilient and responsive to changing circumstances requires our collective thinking to mirror those qualities. We must be tolerant of, even welcoming to, ambiguity. And become as comfortable with conceptual modeling as we are with literal coding.

Yet, most of the approaches we've learned (or are forced to adopt) seek to make everything "concrete" as quickly as possible while taming, subduing and minimizing ambiguity. Keep all that is in darkness out of sight.

This approach would be wonderful, easeful, if it worked. Alas, hiding ambiquity is also known as "technical debt". Ambiguity, doubt or uncertainty, pervade everything we will ever work on. We need soundness and strong foundations. While remembering that when concrete expands or contracts, it breaks.

How do we structure "concrete" work while leaving "just enough" conceptual space around it?

In this talk, we'll explore

- Why ambiguity is valuable and how to orchestrate, rather than subdue, it.

- How architecting ambiguity into conceptual artifacts is often more trustworthy than Gantt Charts. (Though project artifacts work best in congruity with each other.)

- Structuring communication styles that will transform organizational schisms and silos into a rich harmony.

- Changing your own thinking: aka the hardest part.

Wherever your organization is on their path to adopting systems-thinking type approaches, you can begin making a difference right now with these tools.