Diana Montalion's Speaker Profile @ Sessionize

Using The Iceberg Model to Improve Sociotechnical Systems

Systems experts have taught us how to improve our software systems: First, understand that technology systems are always, also people systems. Second, recognize that we need to think in systems.

Peter Senge has demonstrated that we blame the wrong things (events, situations or processes) for our systemic problems. W. Edwards Deming says that 94% of the time, the system is to blame for performance issues, not the individual parts of the system, Jay Forrester discovered counterintuitiveness: most organizations “fix” systemic problems by inadvertently making them worse. Donella Meadows said, “We'll go down in history as the first society that wouldn't save itself because it wasn't cost-effective.”

In this workshop, we will use the Iceberg Model to explore a complex system challenge. As a software professional, you can use this approach whenever you want to understand the root cause of a system challenge. The system we will focus on is one we all know: the technology industry.

Specifically, we’ll use the Iceberg Model to uncover the core mental models, patterns and structures that generate and reinforce patriarchy in software development.

In 2022, 92% of developers were male. Software development is a patriarchal system: a system in which men hold the power and women are largely excluded from it. Despite sincere efforts, this outcome persists, which indicates that we are blaming, and changing, the wrong things. Let’s dive deeper (together).

We will:
- Understand the value of the Iceberg Model.
- Explore the structures and patterns that reinforce patriarchy in software development.
- Identify core mental models that reinforce those structures and patterns.
- Understand the impact on software and systems design.
- Envision (together) a target system architecture – what might the world look like if a radical change is possible?
- Model and explore ways we can positively impact the current system.

Patriarchy creates dichotomies – us vs them, men vs women. We won’t reinforce that mental model. Instead, we will practice identifying reinforcing feedback loops and introduce a tool for analyzing them.

https://bootcamp.uxdesign.cc/systems-thinking-the-iceberg-model-6294bc5346f0
https://www.statista.com/statistics/1126823/worldwide-developer-gender/

Writing as a Core Practice

At DDD conferences, we focus a lot on modeling and not on writing. But most of us working as systems designers do A LOT of communicating. Writing is a fabulous tool for thinking.

As software designers, we craft knowledge. We weave other people’s thinking and experiences into our own. We solve problems. We construct valuable recommendations and improve them through communication.

We envision what is not yet visible and bring it to life.

We also get lost in the forest of disparate opinions. We go down promising paths and discover dead ends. When we do discover a viable path … almost nobody follows us .

We are sometimes screaming into the wind.

Constructing something whole and actionable from abstract ideas requires creating conceptual integrity. Fred Brooks says "Conceptual integrity is the most important consideration in systems design." Unfortunately, we are truly terrible at creating or maintaining conceptual integrity … unless we are supported by practices.

Fortunately, writing is the practice of crafting conceptual integrity.

Writing practices can help us:
- strengthen metacognition: awareness of our own thought process.
- synthesize knowledge, experience and sound judgment into well-reasoned recommendations.
- learn.
- navigate uncertainty through inquiry.
- think well, together.

Thinking well together generates better outcomes. And makes daily life more enjoyable for everyone. When people cooperatively strengthen their thinking, and reasons for acting, they make better decisions.

In this hands-on lab, we will write. You'll try five writing practices that, when done regularly, improve your ability to think, learn and lead. Including timed free writing, systemic reasoning, modeling artifacts and structuring recommendations for varying audiences.

Fair warning: it will be a lot of fun.

Bring your favorite pen.

Workshop: Learning Systems Thinking

A decade ago, developers built information-sharing software by writing a lot of custom code in a single code base, then adding layers of caching. Now we build information systems: interdependent software and services, data platforms, and event streams.

Many of our software-to-systems initiatives fail, though, and when they do, we double down on traditional linear approaches. But linear thinking cannot resolve systems challenges. We need to shift to systems thinking.

This workshop shows software developers and architects how systems thinking is a much-needed skill, given the emerging complexity of modern systems. Nonlinear approaches to technology architecture can transform how we learn, communicate, and collaborate with others.

Through hands-on exercises and real-world scenarios, you'll learn how to develop critical self-reflection and decision-making skill, model systems thinking and thrive amid complexity and uncertainty. Regardless of your role, these skills will help you lead impactful cultural change within your organization.

You'll learn:

- How linear thinking limits your perspective on software systems
- The obstacles to changing your perspective and how to move past them
- How systems and nonlinear thinking help you understand and navigate complex issues arising from internal and external factors
- Methods for creating sound, cross-functional recommendations in the midst of complexity and uncertainty
- How nonlinear approaches improve the quality of architectural thinking and deliver impactful change for organizations
- How writing, thinking and modeling are deep, impactful architecture practices
- How to provide a modern style of leadership as software becomes information systems

Systems are communication structures

Our systems mirror our thinking and collective communication. When architecting, we are synthesizing people's knowledge, experience and good judgement. We are unionizing people's creation process to build them. Achieving conceptual integrity in a system requires crafting conceptual integrity in people.

The art and science of collective reasoning predates technology by seven centuries. Our software and systems design work is strengthened by practicing strong sociotechnical methods for making logical and consistent decisions *based on valid reasons*. This talk will highlight those practices and discuss some modern-challenges to thinking well together.

Tools for Systems Thinking

There are many digital tools to support linear coordination of software delivery. Jira, for example. But what do we do as complexity increases? What tools support the process of reasoning about something, forming new ideas or concepts? How do we develop a collection of tools that support our creative thinking process? How do we use those tools to think well, together?

In this workshop, Diana and Dawn will share their divergent toolset and processes for systems thinking. Then guide attendees towards building their toolkit:

- Identify my primary thinking (alone and together) activities
- Survey the tools I use now and why.
- Design a better system of inter-related tools to support my thinking.
- Consider an improve workflow in my day-to-day focused thinking delivery process.

Stay in the flow: orchestrating ambiguity

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.

Speaking truth to power: a foundational skillset

As complexity increases, are you (too often) shouting into the wind? Do you see icebergs ahead yet fail to convince others to avoid them? Are your architecture-focused discussions more exhausting than productive? Does the accountant understand the value of your work?

The thinking and communication skills we've developed on the job often fail us when we face more-complex challenges. That is why we are learning DDD. Rather than double down on code-specific solutions, we are developing different, more effective conceptual approaches.

Yet, there is an underlying skillset the nourishes and supports our ability to practice DDD or any approach that challenges traditional "power" structures. In this workshop, we'll focus on that skillset.

We'll explore the four fundamental truths:

- Conway was right: communication architects software and systems

- Uncertainty is always a factor

- Fred Brooks was right: conceptual integrity matters most

- Continuous learning is essential: the modern hero is the person who weaves everyone else's expertise into a cohesive, trustworthy whole

And we'll explore four fundamental practices:

- Argumentation: creating strong and valid solutions based on sound reasoning

- Structuring collective reasoning: thinking well together

- Recognizing conceptual fallacies

- Cultivating the right types of energy: aka thoughts are only part of communication

In this talk, I'll link to practice materials to try at home.

Part 2 / Day 2 - Reasoning systematically: the art of integration leadership

When building modern architectures, the hard part isn’t learning Kubernetes. The hard part is changing the way (almost) everyone thinks. If we don’t transform our mental models and communication patterns, we will deliver the exact same system we already have. Regardless of how performant our microservices are.

Everyone can develop confidence in the thinking they facilitate. To develop trustworthy thinking, we need to practice argumentation: reasoning systematically in support of an idea, action, or theory. This systemic reasoning is the key to all transformational success because it delivers Integration Leadership. We apply this leadership as:

- a method of inquiry
- a skill we must practice
- the integration of differing points of view
- good judgement
- the process of enabling others to make up their own mind

Systemic reasoning enables people to communicate about
systems, collectively arriving at the best possible solution, under the circumstances, when conditions are uncertain. (Conditions are always uncertain.)

Developing this skill contributes more value than our technology-specific expertise. In this workshop, we’ll explore methods for providing integrative leadership by crafting sound reasoning, together.

Feedback from previous workshops:
" I am often involved in such discussions as receiver of arguments and in most cases the offered solution only solves symptoms, doesn’t go deep enough. Now I have an advice ready why and how to go deeper."

"I went in with something that was more of a vague frustration for me and ended up with a well-organized argument that I’d feel comfortable bringing up with anyone."

"It changed my way of thinking and challenging others"

Part 1 / Day 1 - Reasoning systematically: the art of integration leadership

When building modern architectures, the hard part isn’t learning Kubernetes. The hard part is changing the way (almost) everyone thinks. If we don’t transform our mental models and communication patterns, we will deliver the exact same system we already have. Regardless of how performant our microservices are.

Everyone can develop confidence in the thinking they facilitate. To develop trustworthy thinking, we need to practice argumentation: reasoning systematically in support of an idea, action, or theory. This systemic reasoning is the key to all transformational success because it delivers Integration Leadership. We apply this leadership as:

- a method of inquiry
- a skill we must practice
- the integration of differing points of view
- good judgement
- the process of enabling others to make up their own mind

Systemic reasoning enables people to communicate about
systems, collectively arriving at the best possible solution, under the circumstances, when conditions are uncertain. (Conditions are always uncertain.)

Developing this skill contributes more value than our technology-specific expertise. In this workshop, we’ll explore methods for providing integrative leadership by crafting sound reasoning, together.

Feedback from previous workshops:
" I am often involved in such discussions as receiver of arguments and in most cases the offered solution only solves symptoms, doesn’t go deep enough. Now I have an advice ready why and how to go deeper."

"I went in with something that was more of a vague frustration for me and ended up with a well-organized argument that I’d feel comfortable bringing up with anyone."

"It changed my way of thinking and challenging others"

Orchestrating ambiguity

Designing software and systems that are flexible, resilient and responsive to changing circumstances requires thinking that mirrors those qualities. We must become tolerant of, even welcoming to, ambiguity.

Yet, most of the approaches we've learned (or are forced to adopt) seek to make everything "concrete" as quickly as possible while hiding ambiguity in the proverbial closet. We know this doesn't work, when concrete expands or contracts, it breaks.

This is why we are here! To become comfortable with conceptual modeling as an essential precursor to literal coding. We are here to conceptually grapple with ambiguity together, doubt or uncertainty, because it pervades everything we will ever work on.

Alas, the rest of the world is not here. We must still go back and engage in circumstances that don't mirror our emerging comfort with orchestrating ambiguity.

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.

Nonlinear Thinking: Skills We Need Now

16 years ago, my teammates and I built software for big internet properties. We spun up a single instance of open-source software, then added a lot of custom code. Now, we build information systems – data platforms, decoupled frontends, event streams, lots of interdependent software and services with many types of consumers.

In the world of “digital transformation”, software is becoming systems. While organizations keep hitting the same iceberg … we don’t think in systems.

Systems are nonlinear. They reorganize our mental models and communication structures. Yes, we need to learn cloud-native architectures, Kafka, Kubernetes, GoLang, Terraforming, etc. But we also need to transform how we think, alone and together, or we will build the same old things with fancy new tools.

In this talk, we’ll explore essential nonlinear skills and practices for IT professionals. Skills we might not think of as “IT”. Yet these essential practices help us navigate from software to systems.

Learning Systems Thinking

This training is for software developers and architects who want to deliver impactful change to modern software systems.

As the relational complexity of our software systems increases, our traditional linear approaches, reductionistic and analytical, are insufficient. We also need systems thinking skills, nonlinear skills that help us to understand how interrelated and interdependent parts act together to create patterns and processes.

We can't do this alone - we need to think well with others.

Systems thinking requires practice. Including modeling practices that support deep, impactful architectural change. Systems thinking practices provide systems leadership. Regardless of your role, these skills will help you lead impactful systemic change within your organization.

This training will introduce you to fundamental systems thinking practices. You will learn to:

- Communicate well-reasoned ideas, recommendations and theories.
- Improve you metacognition and recognize thinking patterns that are reactive or fallacious.
- Create conceptual models, alone and with others, to guide impactful decisions.
- Understand the systemic structures and feedback loops that block change.
- Discover the mental models that are the root cause of reoccurring, "won't fix" problems.
- View challenges as inherently sociotechnical and shift perspective easily to explore challenges from different points of view.
- Structure discovery, learning and exploration with others proactively.
- Accept that uncertainty is a natural, welcome and inevitable part of knowledge work.

Through hands-on exercises, exciting group modeling and building a real-world recommendation, you'll learn how to thrive amid complexity and uncertainty.

Interpretive Dance as an aid to Software Modeling

When we talk about technology architecture, we generally focus on code, infrastructure and domain modeling. We gather together in person or via Zoom in a design session or in a conference workshop talk and talk. We often talk about improving methods of thinking, alone and together.

In this workshop, we’ll explore *embodied* practices that help us think better as individuals and as a group. Physical practices can be the fast train to open our minds to new and changing ideas. Especially when our thoughts are stuck in a rut. You’ll learn activities that:
- Open your mind and improve the flow of ideas
- Increase your energy and change how you feel (when reacting)
- Change how you think, personally and as a group

Modeling is a group activity, even when we do some of it alone.. What is it about a group that allows modeling? In the arts, we see nuances when we watch a play that would not be clear when reading the script. In improvisational comedy, people have learned how to think well, collaboratively and in real time. Is there something we can learn from that? We will explore methods of working and thinking together as a group that will improve our collective thinking and modeling.

Join us in this fun and very unique workshop where we will do a different kind of modeling. An approach that will strengthen our architectural influence and make us better-reasoned thinkers.

From software to systems: skills we need now

16 years ago, my teammates and I built software for big internet properties. We spun up a single instance of open-source software and added a lot of custom code. Nowadays, we build information systems - data platforms, decoupled frontends, microservices, event streams. Our software is interdependent services with many types of consumers.

In the world of "digital transformation", software is becoming systems. Unfortunately, we don't think in systems.

Systems are nonlinear. Our focus is shifts from feature development to orchestrating relationships between parts, achieving something that would not exist without those well-designed relationships.

The same is true for the people building systems. Systems reorganize our mental models and communication structures. In response, we must transform how we think together, or we will build the same old things with fancy new tools.

Yes, we need cloud-native architectures, Kafka, Kubernetes, GoLang, Terraforming, EventStorming etc. We also need some essential nonlinear thinking and communication skills. We may not think of them as "IT" skills. (Yet.) Nonetheless, they are essential for navigating from software to systems.

From Software to Systems: Modern Agility

Early in my career, I worked on highly-productive Agile teams building software for big internet properties. Ten years (or so) later, I worked as principal systems architect for some of the same organizations. Everyone needed "digital transformation" to move away from legacy software (some I helped build). Which meant moving away from working as one feature-driven team to architecting across multiple product and platform teams.

On social media, I regularly see "agile is dead". "Agile didn't keep up with the times." Or other disparagements of agility. My experience has been the opposite. Teams without fundamental mental and social agility can't scale (effectively) as the architecture becomes more inter-relational.

In this talk, we'll explore the key patterns and principles that maintain cohesion, communication and conceptual integrity as software scales to systems of software. And how the skills Agile taught me have scaled to integral skills for architects.

(Note: I will not recommend SAFe.)

Don't Hit the Iceberg

A decade ago, developers built information-sharing software by writing a lot of custom code in a single code base, then adding layers of caching. Now we build information systems: interdependent software and services, data platforms, and event streams.

In systems thinking circles, a common model is The Iceberg. At the top, visible above the waterline, are the things that happen. Events (like bugs and outages) and patterns that reinforce them. At the bottom, down deep, are our mental models -- the concepts we draw from when we build software systems.

I've seen many software-to-systems (aka "digital transformation") initiatives fail. They hit this Iceberg and sink spectacularly. What do we do when that happens? We double down on our traditional approaches.

Real transformation can only happen when we go deep into the structures of our collective thinking. Architecture, in the systems age, is not just Kubernetes. It is engaging our mental models and working together to transform them.

Our thinking designs our architecture. Scaling up our linear thinking cannot resolve systems challenges. We need to shift to systems thinking.

DDD for Total Newbies

When you come to your first DDD Conference, or read a DDD book, or join an EventStorming workshop, you might feel overwhelmed by the new concepts. You might feel shy about asking questions, feeling like everyone else knows what a bounded context is ... but you don't.

This workshop is for people who are brand new to the whole DDD thing. We will create a safe and supportive space to explore the basic concepts.

- Where do I begin?
- What are the three important things to understand?
- What resources help me get started?

Even if this isn't your first conference but you'd like an "overview of the basics", you are welcome. Before the workshop, I will gather your questions and leave time to answer them.

And I will tell you the truth: Even seasoned experts are still trying to understand what "DDD" is ... and we welcome you to the party.

Collective Architecture - Live RPG Experience

(This is a hands-on lab with limited capacity)

Welcome to Mago! Mago is the most-read magazine and digital product producer in the world. Today is your first day as an architect. Welcome architect! You were hired just in time! As the CEO will tell you, a crisis is looming. You and your teammates will create a recommendation … what do we do next?

Your five teammates are aligned with somewhat-different Points of View. You’ll interact with the Chief Architect, Chief Data Officer, Chief Product Officer, CTO and the very-busy Managing Editor (aka the NPCs). You’ll see some models. You’ll seek advice from NPCs who know how the system works. You’ll think together. You’ll find signal in the noise.

Nobody knows how the game will end.

In this First of It’s Kind RPG workshop, you’ll enjoy the egalitarian experience of “doing architecture” as a collective, cross-functional practice. In daily life, we are surrounded by increasing relational complexity, our need for relationally-smart architect practices is increasing along with it. Regardless of your role, you can work with others to make architectural recommendations and evolve towards architecture as a collective practice.

When done well, this practice delivers domain-aligned, team-decoupling, cohesiveness-driving, constantly-evolving impactful recommendations. Today, we’ll have some fun strengthening our real-world skills:
- Build an architectural recommendation, as a group
- Give and receive architectural advice
- Practice systemic reasoning and deliver a sound recommendation
- Pivot and adapt as systemic constraints are revealed via feedback
- Create a new mental model using pieces of the current model
- Create signal in the midst of noise
- Have wicked fun doing it, together

We will learn from each other about communication, decision making and the fine art of improvisational systems design.

Note: This workshop is extended, 2.5 hours long with an optional After Party discussion group.

Architecture over Architects

As the relational complexity of software increases, we need, more than ever, smart architecture. Domain-aligned, team-decoupling, cohesiveness-driving, constantly evolving architecture has a massive positive impact. To design systems, we need to evolve the role of “architect” away from the dualistic most-experienced implementor vs ivory tower strategist.

Architecture is a technology-agnostic skillset. You practice it regardless of which tools or programming language you work with. Architecture is a solitary, intra-group, and inter-group activity. We practice it within the human system, when we collaboratively design patterns and relationships, empower decision making and construct cross-functional feedback loops.

We'll explore:
“What is an architectural decision?” (The answers might surprise you.)
How do we work effectively individually, intra-team, and inter-team to make them?
What is the “advice process” and what has it taught us?
What goes wrong (all the time) and what to do about it.

Architecture isn't Kubernetes

One of the most contentious words in technology culture today is “Architect.” I experience an endless stream of divisive, confusing opinions about what "architecture" means. At a conference, an attendee noticed that my badge said "architect" and told me "I want to be an architect too, but I don't know enough about Kubernetes yet".

Architecture, in the systems age, is not (just) Kubernetes. It's not the implementation of any particular toolset. Architecture is designing relationships between parts and adapting those relationship patterns as circumstances change. This requires engaging our mental models and working together to transform them.

The architecture skillset is sociotechnical -- a blend of social and technology skills. In the modern age, there is no division between the way we think together and the code running in production. Our thinking designs our architecture. Architecture is structuring good systems thinking.

In this talk, I will admit that *sometimes* architecture is Kubernetes. And share five essential qualities that make a good architect a great architect, regardless of the toolset they employ.

Nonlinear Thinking

We are conditioned to think linearly. Linear thinking is so ubiquitous, many of us don’t recognize it as one type of thinking. We think of it as, simply, thinking. Linear thinking enables us to design, build and deploy software. But it can not resolve systemic issues. For systems, we need to think nonlinearly.

Though we may be brilliant software developers, product managers or strategic leaders, when it comes to nonlinear thinking, we are all blocked by two obstacles:

One: By default, we are spectacularly terrible at nonlinear thinking*. We are constantly tangled up in our opinions, cognitive biases, fears, assumptions, linear conditioning and logical fallacies. They seem real and true to us. Skillfully and consistently untangling ourselves requires practice.

Two: We don't know that we are terrible at it. In fact, the worse we are at nonlinear thinking, the more certain we are that we are good at it!

Therein lies a paradox: We need to be good at nonlinear thinking in order to see that we aren't good at nonlinear thinking. Fortunately, as Carl Jung said, “Only the paradox comes anywhere near to comprehending the fullness of life.”

In this workshop, we will "comprehend the fullness" with helpful principles and practices on three levels: individual, teams/groups and a system as a whole.

30 mins:
- Practices for cultivating self awareness and improving the soundness of our own thinking. We begin here because what we think and experience is what we'll build. While we'll only have time to do one or two, we'll introduce varied resources to continue exploring.

30 mins:
- The "Yes, and" game. We'll practice collective reasoning by following a few fundamental rules for thinking nonlinearly together. This is a warm up for ...

1 hour:
- "Where shall we begin?" We'll model an interesting (likely familiar) real world systems challenge. In this challenge, there is no linear path to transformation - we'll need to take a nonlinear approach. We'll focus on patterns and relationship as well as blockers, challenges, feedback loops. We can apply DDD concepts or we can mix and match. We won't Solve Everything. But we will create some structured thinking in the midst of uncertainty.

* Nonlinear thinking is also called systems thinking, strategic thinking, pattern thinking, parallel thinking, systemic reasoning and other names.

Reasoning systematically: the art of integration leadership

Practice argumentation, the foundational skillset for navigating uncertainty

Systems Thinking for Software Professionals

Systems experts have taught us how to improve our software systems:

- Peter Senge has demonstrated that we blame the wrong things (events, situations or processes) for our systemic problems.
- W. Edwards Deming says that 94% of the time, the system is to blame for performance issues, not the individual parts of the system.
- Jay Forrester discovered counterintuitiveness: most organizations “fix” systemic problems by inadvertently making them worse.
- Donella Meadows said, “We'll go down in history as the first society that wouldn't save itself because it wasn't cost-effective.”

As relational complexity increases, we need to think in systems. I don't just mean adopt Kubernetes. Technology systems are always, also, people systems. Without systems thinking, nothing is transformed. As Robert Pirsig said,

"If a factory is torn down but the rationality which produced it is left standing, then that rationality will simply produce another factory."

Systems thinking is becoming a core and critical skill. The Iceberg Model, for example, helps us understand "the rationality that produced" our current situation. As a software professional, you can use itwhenever you want to understand the root cause of a system challenge.

Using tools like the iceberg model is deceptively simple. Avoiding the iceberg ... takes committed practice.

Most Active Speaker

Diana Montalion

Actions

Links

Awards

Area of Expertise

Topics

Sessions