Kenny (Baas) Schwegler
Catalysing teams to design sustainable, resilient software through leadership and sociotechnical expertise.
Amsterdam, The Netherlands
Actions
I believe in collaborative software design where *‘every voice shapes the software’*. Leveraging a domain-driven design approach with Team Topologies, I facilitate clearer communication between stakeholders and software creators by collaborative modelling and deep democracy, decoding complexities, resolving conflicts and ensuring software remains agile to business demands.
As an independent software consultant and trainer, I specialise in technical leadership, software architecture, and sociotechnical system design. I work with organisations and teams to design and build sustainable and resilient software architecture.
Links
Badges
Area of Expertise
Topics
Interactively designing distributed systems integration with collaborative modelling
This is a hands-on lab with limited capacity.
Want to get a deeper understanding of the strengths and limits of each collaborative modelling approach and how they can be effectively applied to design distributed systems integration?
Designing distributed systems requires us to constantly balance the complexity within the systems themselves and the complexity in their integration. While we can't eliminate essential complexity, there are numerous ways to approach distributed systems integration. Tools like Domain Storytelling, EventStorming, Wardley Mapping, and Domain Message-Flow Modelling offer a structured way to explore and evaluate these integration boundaries. By applying these tools, we can assess the broader sociotechnical system and optimise it collaboratively. This process helps us address key questions—ranging from team ownership and communication, to determining the data that should flow between systems, and identifying the most suitable strategic and message-driven patterns for each interaction.
In this hands-on session, we will delve into designing distributed systems integration using Domain Storytelling, EventStorming, Wardley Mapping, and Domain Message-Flow Modelling. We’ll start by going through a simple Domain Storytelling to clarify the problem we’re aiming to solve. Afterward, we’ll split into groups, each using a different collaborative modelling tool—whether it’s Domain Storytelling, EventStorming, Wardley Mapping, or Domain Message-Flow Modelling. Each team will be guided by a facilitator who will help navigate the modelling process, applying a distinct tool to address the same challenge. At the end of the session, each group will present their findings, showcasing the patterns they discovered and the trade-offs they encountered. You will leave with a deeper understanding of the strengths and limits of each collaborative modelling approach and how they can be effectively applied to design distributed systems integration.
Enabling aligned decentralised architecture decisions through user needs mapping
Our goal is to help teams maintain their delivery flow, enabling them to focus on consistently delivering business value without getting held up by dependencies. Achieving this often requires decentralised architecture decisions, empowering teams to act independently. But decentralisation comes with risks. A decision made to optimise for one team’s users can unintentionally reduce resilience or disrupt the user experience for other teams downstream. To avoid this, teams are forced to consider organisation-wide impacts, which increases cognitive load and disrupts flow. The challenge is clear: how can teams stay aligned while making decentralised decisions without becoming overwhelmed?
Join this hands-on session to learn how user needs mapping enables aligned decentralised architecture decisions. User needs mapping is the value chain layer of a Wardley Map, enhanced with clearly defined team responsibilities. Working in groups, you’ll take on the role of a software team with a unique context and landscape. Starting with your user and their needs, you’ll map the software components required and outline your team’s boundaries, uncovering knowledge gaps along the way. Once your team map is complete, you’ll collaborate with others to fill in those gaps, map dependencies, and refine your value chain. By the end, you’ll understand how to create and maintain user needs maps that support resilient, informed decisions while keeping them actionable over time.
Enabling aligned decentralised architecture decisions through user needs mapping
Our goal is to enable teams to maintain their flow of delivery, allowing them to focus on delivering continuous business value without being held up by dependencies on other teams. This requires teams to make decentralised architecture decisions whenever possible. However, decentralised decisions can have unintended consequences across the organisation. For example, a team’s decision to optimise for their specific user might negatively affect the resilience or user experience of another team downstream. To prevent this, teams are often forced to consider the wider organisational impact of each decision, which adds to their cognitive load and disrupts their flow. The challenge is: how do we foster alignment across teams so they can make decentralised architecture decisions without being overwhelmed by the complexity?
Join us in our talk as we demonstrate how we embedded user needs mapping within an organisation to enable aligned decentralised architecture decisions. User needs mapping is the value chain component of a Wardley Map, enriched with clear team responsibilities. By using this value chain and defining responsibility boundaries, teams gain a clear map of what is needed to address their users' needs. It also highlights which other teams—whether stream-aligned or platform teams—are involved. This allows teams to engage in meaningful conversations to identify dependencies and requirements across the organisation. By mapping these onto other teams’ user needs maps, we create a foundation for teams to rapidly understand the impact of their decisions and their interactions, resulting in more resilient and informed decentralised decisions. You'll walk away with insights into how we facilitated these sessions with the teams, and how we ensured the maps remain current and actionable.
Autonomy, is that what we really want?
There has been a focus on autonomy in information technology, From autonomy in code, autonomy while coding, and autonomous systems with microservices to autonomous high-performing teams. When you read Daniel Pink's research in the book Drive, it makes sense; autonomy is one of the three things that motivate us; it is the ability of the person to make their own decisions. However, often autonomy can lead to isolation and disconnect from the rest of the code, team, or organisation. So, how can we balance the individual needs while staying connected to the team/organisation to stay autonomous?
In this talk, we will go through all the levels we deal with in IT, from code to organisation collaboration. We will go into autonomy at each level and explain how we often confuse autonomy with individual needs. These individual needs can become isolated and disconnected from the code, team and organisation. Through examples, we will show how our compulsiveness towards autonomy gives us both downsides of being isolated and coupled in the code within the team and organisation. You will leave the talk knowing how polarity management can help you manage this paradox between the individual and the team/organisation and get the benefits from the whole and the individual to be balanced.
Facilitating collaborative design decisions
If we want to make sustainable design decisions for our architecture that are embraced by everyone, the most effective way is to do this collaboratively. Everyone can feel a part of the decision, and can potentially give the input they have. The group is aligned and knows what is to be expected onward. On paper this sounds great, but in reality we know it is hard to do because we need to deal with all sorts of group dynamics. Dynamics like cultural differences, conflicts of opinions, cognitive biases, and polarities that the group are part of. These dynamics cause people to stop sharing what they want, which ends up in resistance behaviour from sarcastic jokes, to stopped communication or leaving the session. No wonder a lot of people resort to a more autocratic form of decision making, where the architect analyzes and makes the decision. So how can we make collaborative decision decisions better?
Join Gien, Evelyn and Kenny in this hands-on workshop where we explore different models of decision making that can help facilitate collaborative design decisions. We will dive into a variety of facilitation techniques such as:
Working with climate reports to trigger hidden group conflicts
Visualising trade-offs of different models with the pro-con-fix list
Taking group decisions with full buy in with Deep Democracy
Domain boundaries are not enough: Connect Contexts and Services
Have you ever wondered why some software seems to be disconnected or even constantly fighting the business, while other systems grow naturally from it? The answer lies in domain modelling.
This talk explores the importance of continuously defining and modelling domain boundaries to design adaptable and resilient software systems. You'll leave with a clear understanding of what a subdomain is, how it differs from a bounded context and a service boundary, and why grasping this distinction is fundamental to good architecture.
Modelling domain boundaries with stakeholders is essential for building good software. We will explain how they are related to, yet distinct from, service boundaries and bounded contexts. We'll also present why designing and continuously adjusting these boundaries based on feedback is a good habit for creating software that aligns with the business and generates new opportunities.
We won't shy away from the complex challenges, either: the resistance to change, the disconnect between an ideal future and the weight of legacy systems, and the struggle of getting a group to agree on what a "customer" even means.
You'll get practical insights and design heuristics on how to collaboratively model these boundaries using techniques like Big Picture EventStorming, Domain Storytelling, Wardley Mapping, and Context Mapping.
Debiasing Your Software Design Decision-Making
Every significant software design choice—whether you’re designing a bounded context, deciding on the system boundary, settling on an architectural style, selecting a complex system integration approach, and even evaluating a block of AI-generated code—has a moment where one path just feels right. But what if that powerful 'gut feeling' is actually a cognitive bias in disguise?
The human mind is a powerful tool, yet it is systematically prone to errors. These errors aren't just abstract ideas; they are design flaws in our own decision-making that can lead directly to fragile architectures, ballooning technical debt, and costly rework, regardless of whether the code was human or machine-generated. Biases like the anchoring effect (getting stuck on the first idea) or the sunk cost fallacy (clinging to a failing project) are constantly shaping your software.
Join us to move from a reactive, bias-driven approach to a deliberate, resilient, and ultimately more effective design process. This talk explores how cutting-edge research from behavioural economics can be applied directly to software architecture and development, with or without AI assistance.
We will move beyond simply being aware of biases. We will introduce a practical, five-step checklist designed to systematically 'debias' your design choices, helping you build both better software and a better decision-making habit for all your technical work.
You will learn how to:
- Be Decision-Ready: Recognise when you and your team are in the right mental and emotional state to make critical decisions, avoiding biases that arise from fatigue or emotional haste.
- Broaden the Frame: Combat functional fixedness and additive bias by intentionally exploring a wider range of solutions—including options that remove complexity—to avoid getting fixated on a single, suboptimal idea.
- Seek Independent Advice: Move past overconfidence and the false-consensus effect by actively soliciting diverse, external perspectives and taking an "outside view" on how similar challenges have succeeded or failed.
- Test Your Assumptions: Inoculate your team against loss aversion and the sunk cost fallacy by running a pre-mortem and appointing a devil’s advocate, preparing for potential failure before it even happens.
- Establish Simple Rules: Avoid the law of triviality and the availability bias by creating objective, repeatable criteria that guide your choices and ensure you focus on what truly matters.
Deep Dive into Model-Driven Design: Refining Domain Models in Code
Most software products begin with an initial software model, one that is typically naive and superficial, grounded in basic understanding. This initial phase is natural, as it aligns with the early stages of discovering and exploring a new product with stakeholders. Initially, the process involves identifying nouns and verbs to create the first objects and methods in our code. While this early model enables quick feedback for the product, it often becomes less effective over time. As more feedback is gathered, the model usually fails to accurately reflect the main concerns of domain experts, becoming less relevant for the product's development. The absence of a model that mirrors the domain's core aspects can prevent adjustments to the code based on changing stakeholder needs, potentially blocking product innovations. Additionally, the gap between the code and the domain model leads to missed opportunities for insights, as the code no longer represents our domain knowledge accurately.
Join us in this live coding talk session focused on the significance of continuously refining your core domain models in code. We will introduce you to the context by guiding you through several collaborative modelling techniques such as Eventstorming, Domain Storytelling, Context Mapping, CRC-cards and more. We then dive into coding challenges using C# where you'll witness firsthand the transformative power of supple design and a deeper model. By the end, you'll understand how continuously refactoring the model can be pivotal in driving product development breakthroughs. You'll depart with enriched practical insights and a Deep Dive of Part III of Evans’s groundbreaking work on Domain-Driven Design (DDD) that goes beyond basic concepts like aggregates, entities, and value objects.
Tackling Social-technical complexity in the heart of your team
As a software engineering team, we want to solve complex business problems in the most efficient way possible. We invest a lot in technology to improve our team flow and try to make our technology process sustainable. We’ve got quite compulsive about automation and autonomy in achieving this. However, we are still tribal creatures that require tribal safety. Which means that if we want to make our technology process sustainable, we must also invest in people. For that, we need to tackle socio-technical complexity in the heart of our team.
In this session, Evelyn and Kenny will introduce you to the concept of socio-technical systems. We will explain what socio-technical complexity we are facing when building software to improve our team flow. How you can get a sense of the type of complexity you’re dealing with by using the Cynefin framework. Cynefin can aid your decision-making process by helping you make less biased decisions on how to approach your software development flow with your team. Finally, we’ll show you how visual collaboration tools like EventStorming and many others that can help you visualise complexity. You will leave this session knowing how to start tackling socio-technical complexity in your team. Making sure you create a sustainable technology process for your team flow!
Does culture impact software design?
(This is a hands-on lab with limited capacity)
DDD is about understanding and communicating complexity. We have long recognized that the most effective way to communicate complexity is via human language. But language poses a challenge when working in a team comprised of members of different (sub)cultures and nationalities, each with a native language that might not be the same as the language we are communicating in. Each of these cultures has a different perception about how to communicate effectively. By way of example, in some cultures, it is considered appropriate and respectable to use the tentative voice “perhaps we should consider trying X”. Whereas in other cultures it is the assertive voice that is valued “This is how we should do it”.
Assuming that everybody in the room wants to communicate effectively, what aspects can we define that impact our design? What organizational culture fits better with what type of architecture (microservices, monolith)? And what cultural needs must these architectures and boundaries address to succeed? Join us in this hands-on where we together explore these challenges!
Collaborative Software Design: How to facilitate domain modeling decisions
Software is becoming more central to our lives every day, yet creating high-quality software systems remains a significant challenge. This issue largely arises because many software teams focus too heavily on finding solutions rather than understanding the organisational context. To effectively address this, developers must engage and communicate with relevant stakeholders, cutting across various organisational settings and contexts. However, communication with the business side is fraught with potential pitfalls: misunderstandings can occur, individuals may feel intimidated to speak up, tensions might escalate, and conflicts can emerge. These social dynamics can lead to a breakdown in knowledge sharing, manifesting in resistance behaviours ranging from sarcastic comments to complete disengagement or even leaving discussions altogether. As a result, many organisations default to a more autocratic decision-making style, where a single individual, typically the architect, analyses the situation and makes decisions. However, to achieve sustainable and widely supported design decisions for our architecture, it's more effective to employ visual techniques to make assumptions clearer, which in turn improves collaboration between developer teams and domain experts.
In this talk, we will explore collaborative modelling and the social dynamic challenges it presents. Collaborative modelling is a visualisation technique designed to analyse complex and dispute-ridden decision-making processes, bringing together all relevant stakeholders and decision-makers to develop a common understanding. A significant aspect of this approach is the facilitation of sessions to ensure everyone feels included in the decision-making process and is able to contribute their insights. We will highlight the importance of developing a diverse skill set that includes observing, listening, remaining neutral, and showing empathy to foster better collaboration. The objective is to enable software teams to collaborate with their stakeholders, understand their needs, and allow this understanding to guide their software architecture. This is the core of what we define as engaging in collaborative software design!
Collaborative software design for team cognitive load
When navigating the complexities of software design and development, new ideas and future requests frequently cross software and team boundaries. The most effective approach to these design challenges is through collaborative modelling sessions, where teams are directly involved in crafting the software design. Yet, this approach leads us to a critical dilemma: What happens when new capabilities increase the cognitive load on a team, hindering their ability to deliver on both new and ongoing business needs? And how do we address situations where these new capabilities clash with our current architecture, leading to necessary changes that don't fit our existing team structures? Our goal is always to create the best architecture for our business challenges, but this depends heavily on our teams' delivery capabilities. This brings us to a fundamental question: If our teams face difficulties in implementing what is ideally the 'best' architecture, can we still consider it the most effective solution?
Join us in this interactive, hands-on session, where you will delve into a real-world software design challenge that intersects both software and team boundaries. Equipped with detailed context and comprehensive software diagrams, you will design in groups two potential software designs. You are free to approach the challenge in any way you prefer, and we will provide a message flow modelling template to help you quickly start addressing your challenge.
From those initial two designs, we will introduce you to the fundamental principles of Team Topologies, focusing on how cognitive load affects the teams involved and your software design. This understanding of cognitive load will be crucial as we further explore more solutions to the design challenge. Throughout this session, you will gain practical insights into how cognitive load influences your approach to software design. You will learn how to effectively incorporate Team Topologies into your design decisions. By the end of this experience, you will have hands-on software design experience, tackling complex design challenges with a team-first approach.
Effective software design: The role of men in debugging patriarchy in IT
Effective software design relies on integrating diverse perspectives throughout its development process. Research shows that teams with a neuro-diverse background excel in decision-making due to their ability to consider a wider range of ideas, foresee a greater variety of potential challenges, and develop more creative solutions. This becomes particularly clear in collaborative modelling for Domain-Driven Design. The inclusion of varied viewpoints enhances the ability of software models to address business problems effectively, increasing the likelihood of achieving significant product breakthroughs.
However, one social system significantly blocks the flow of development of these diverse perspectives: patriarchy. Patriarchy is a social construct where men predominantly hold power and exercise dominance in areas such as political leadership, moral authority, social privilege, and property ownership. Feminists have been actively working to challenge and change this patriarchal system for the better. Despite these efforts, the system still favours men, maintaining their dominant status, and will not evolve without their active involvement. Additionally, patriarchy limits men as well, endorsing only traits traditionally seen as 'masculine' and disregarding those seen as 'feminine.' This raises the question: how do we start the process of eMANcipation, involve men in the movement towards feminism, and as a result, improve our software design practices?
Join me in this talk as I explore patriarchy and its significant effects on software design. Drawing from personal experiences, I will discuss how patriarchy affects men and argue that for genuine equality, men need to undergo changes too. I will demonstrate how incorporating Process Work and Deep Democracy into software design can bring about the necessary transformation. By adopting the idea of role fluidity, we can start breaking down the patriarchal system in software design, ensuring that every perspective is appreciated and nurtured. You will leave with a deeper understanding of how patriarchy influences software design and practical steps you can immediately apply to foster a shift towards a more inclusive environment.
Newcrafts Paris 2024 Sessionize Event
iSAQB Software Architecture Gathering – Digital 2022 Sessionize Event
KanDDDinsky 2022 Sessionize Event
Techorama Netherlands 2022 Sessionize Event
Kenny (Baas) Schwegler
Catalysing teams to design sustainable, resilient software through leadership and sociotechnical expertise.
Amsterdam, The Netherlands
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top