Introducing The Systemic Event Discovery Approach
Introduction
Transformation looks simple only in hindsight. Once the dust settles, the story becomes neat: there was an old system, a vision for the future, and a sequence of steps connecting the two. Reality is rarely that generous. Most transformations feel like confusion, fatigue, and constant patching. Progress is uneven, priorities shift, and the future state remains uncertain for much longer than anyone expects.
The Problem is that change is designed and executed as a linear journey. The reality is different. A sociotechnical system changes only at the rate its structure allows. Architecture matters, but so do relationships. Teams, incentives, ownership, habits, and long-standing dependencies quietly determine what is possible and what is not. Systems remember. They carry the consequences of past decisions, even when the people who made them are no longer around.
This is not a criticism of ambition or effort. It is a criticism of treating transformation as a project with a predefined end state. Transformation is an ongoing negotiation with constraints, incentives, and learning loops.
In this article, we explore the problem space of sociotechnical system transformation and modernization, as well as the solution space represented by SEDA, an innovative and adaptive approach to navigating complexity and guiding sustainable change.
The Illusion of Software Transformation
Change promises renewal, yet organizations often experience recurrence instead. New initiatives begin with urgency: leadership announcements, task forces, ambitious roadmaps, and fresh language.
What is commonly labeled as resistance is rarely laziness or incompetence. More often, it is the system protecting its existing balance. Sociotechnical systems are not passive objects waiting to be redesigned. They adapt, compensate, and preserve coherence.
This is the transformation paradox. Control is introduced to accelerate change, yet excessive control often reinforces the very structures that prevent change. Plans, steering committees, and dashboards are created to reduce uncertainty, but they frequently reproduce the same assumptions that made transformation necessary in the first place. The tighter transformation is managed, the less room remains for genuine adaptation.
Transformation is therefore not a project to execute, but a tension to navigate. Systems do not resist change; they resist incoherence. When change ignores the relationships, incentives, and constraints that hold a system together, the system absorbs it, normalizes it, and eventually returns to familiar behavior.
Furthermore, Bateson’s observation captures a central challenge of transformation: we often reason linearly about environments that behave non-linearly. Attempts to simplify complexity rarely eliminate it; they merely shift it elsewhere. The resulting workarounds expose dependencies and constraints that would otherwise remain hidden.
The real challenge of transformation lies not in technology alone, but in the feedback loops that turn intentions into collective behavior. Because feedback operates with delays, cause and effect are seldom visible at the same time. What is often perceived as resistance is frequently the system’s attempt to preserve coherence.
Organizations are complex ecosystems whose behavior emerges from relationships rather than instructions. Effective transformation therefore requires more than a plan. It requires continuous sense-making, awareness of interdependencies, and the ability to recognize how small signals can influence the broader environment.
As a matter of fact, transformation is not simply a matter of control, but of design. Sustainable change emerges when organizations understand the conditions that shape behavior rather than reacting to symptoms alone.
This shift, from symptoms to systems, requires a different way of seeing. It encourages us to look beyond isolated events and toward the recurring patterns that influence how sociotechnical systems evolve. Understanding these patterns is the first step toward meaningful and lasting transformation.
Common Anti-Patterns in Sociotechnical Systems Transformation
Despite the effort invested in transformation, familiar outcomes often reappear. Momentum slows, priorities shift, and organizations gradually return to established ways of working. This is rarely the result of a single decision or a lack of commitment. More often, it reflects deeper structures and behaviors that continue to shape the system long after change has begun.

These recurring behaviors are not random. They appear repeatedly across organizations, regardless of industry, technology, or transformation strategy. They emerge as recognizable anti-patterns that undermine progress, reinforce existing dynamics, and make meaningful change difficult to sustain.
The following sections explore some of the most common anti-patterns found in sociotechnical systems and how they influence transformation efforts.
1️⃣ The Wrong Coordination & Collaboration Trap
People are a fundamental pillar of every sociotechnical system, yet transformation often assumes that adding skilled individuals or reorganizing teams will automatically improve outcomes. In practice, the real constraint is frequently the way people collaborate. Unclear responsibilities, fragmented ownership, and ineffective coordination create friction that no amount of individual talent can overcome.
This anti-pattern emerges when organizations invest in people without improving the interactions between them. Teams work hard, but decisions slow down, dependencies increase, and collaboration becomes increasingly difficult. Lasting transformation depends not only on capable people, but on creating an environment where they can make decisions, learn, and work together effectively.
2️⃣ Hidden Infrastructure Constraints
Transformation often begins with ambitious plans for modern architectures and faster delivery. Yet these ambitions are frequently built on infrastructure that was never designed to support them.
Legacy platforms, deployment pipelines, integration layers, and data platforms quietly limit the pace of change long before the architecture itself becomes the problem.
Because these constraints remain largely invisible, teams spend increasing amounts of time working around them rather than removing them. Features are delayed, delivery slows, and technical improvements fail to produce the expected organizational impact. Instead of enabling transformation, the underlying infrastructure gradually becomes its biggest constraint.
3️⃣ Workflow Friction
Processes are introduced to improve quality, reduce risk, and coordinate work. Over time, however, they often outlive the conditions that created them. Additional approvals, handovers, reviews, and coordination steps gradually increase the effort required to deliver change. Instead of supporting collaboration, the workflow begins to slow it.

This anti-pattern emerges when processes are treated as fixed procedures rather than evolving parts of a sociotechnical system. Teams continue to follow the workflow, but responsiveness declines, coordination costs increase, and delivery becomes progressively harder. Sustainable transformation requires workflows that evolve with the organization instead of preserving assumptions from the past.
4️⃣ The Cultural Inertia Trap
Culture is one of the most influential pillars of a sociotechnical system, yet it is often overlooked during transformation. Organizations introduce new technologies, processes, and structures while assuming that new behaviors will naturally follow. In practice, culture continues to reinforce established ways of thinking, collaborating, and making decisions.
This anti-pattern emerges when transformation changes the visible parts of the organization but leaves its underlying assumptions untouched. Teams gradually return to familiar behaviors, not because they oppose change, but because the existing culture continues to reward them. Sustainable transformation therefore requires cultural evolution alongside technical and organizational change.
5️⃣ The Technology-First Trap
Technology Stack is an essential pillar of every sociotechnical system, but it cannot transform an organization on its own. Modern platforms, cloud services, automation, and AI can improve delivery, yet they rarely change how people collaborate, make decisions, or coordinate their work. When organizations expect technology alone to solve systemic problems, they often reproduce existing behaviors on a more advanced platform.
This anti-pattern emerges when technical modernization outpaces organizational evolution. New tools reduce technical friction, but without corresponding changes in culture, processes, and organizational structure, the underlying system remains largely unchanged. Technology becomes an enabler of transformation only when it evolves together with the rest of the sociotechnical ecosystem.
6️⃣ The Directionless Transformation Trap
Clear goals provide direction for every sociotechnical system, yet transformation efforts often prioritize speed over purpose. Teams deliver more frequently, roadmaps accelerate, and progress appears measurable, while the desired outcome becomes increasingly unclear. In these situations, faster delivery does not necessarily produce better results—it simply amplifies existing uncertainty.
This anti-pattern emerges when organizations measure success by activity rather than direction. Without a shared understanding of the intended outcome, teams optimize locally instead of moving collectively. Sustainable transformation requires not only momentum, but a clear sense of where the organization is trying to go and why.
From Recurring Problems to Systemic Understanding
Software Transformation journeys rarely struggles because organizations and ecosystem in general have run out of ideas. The harder challenge is that individual improvements often fail to account for the system around them. A new architecture, a different team structure, faster delivery, or better processes may address only one part of the problem while leaving the relationships between those parts largely untouched.
The anti-patterns described above make this visible. Problems associated with people, processes, culture, technology, infrastructure, and goals may appear independently, yet they influence one another. Changing one without understanding the others can simply move the difficulty elsewhere.
This is where the problem space changes. Instead of asking which initiative, tool, or organizational change should come next, we need to understand how the sociotechnical system behaves as a whole. That shift provides the foundation for SEDA.
Thinking Systemically About Transformation
Transformation starts with understanding the environment in which change has to happen. Acting before understanding that environment can address visible problems while leaving the conditions that created them untouched.
A systemic approach takes a different path. It begins by making the current system visible, then uses what is learned to reconsider boundaries, responsibilities, and relationships. As changes take effect, their consequences become new information: dependencies appear, assumptions are challenged, and new signals emerge. Those signals guide the next decisions rather than being treated simply as deviations from the original plan.

This makes software transformation iterative by nature. Understanding informs change, change reveals new information, and that information shapes what happens next. SEDA turns this way of thinking into four connected steps.
1️⃣ See the System as It Is
To reduce risk and create the conditions for a successful transformation, we should begin by understanding how the current system actually behaves. What appears to be a problem within one team, process, or technical component may be connected to decisions and dependencies elsewhere.
Looking across organizational and technical boundaries helps reveal these relationships and exposes the difference between how the system is expected to work and how it works in practice. Before deciding what to change, we first need to understand the system we already have.
2️⃣ Redesign Around What Matters
Once the current system is understood, attention can shift toward what the organization actually needs to achieve. Existing structures, processes, and responsibilities may have been created for valid reasons, but those reasons can lose relevance as the environment changes.
Redesign means reconnecting these elements with business purpose and value, then reshaping the system around what matters today rather than preserving decisions inherited from the past.
3️⃣ Adapt to What Emerges
Transformation inevitably produces outcomes that could not be anticipated during design. New dependencies become visible, assumptions prove incomplete, and changes in the surrounding environment introduce new constraints.
Instead of treating these developments as deviations from the plan, organizations should use them as information. The ability to observe what emerges, learn from it, and adjust accordingly is what allows transformation to remain relevant as the system evolves.
4️⃣ Keep the System Evolving
Last but not least, software transformation does not end when the first improvements become visible. Every change reshapes the system and creates new conditions, dependencies, and challenges that may require further attention.
Without continuous observation and learning, earlier behaviors can gradually return and new forms of misalignment can emerge. Keeping the system evolving means treating transformation as an ongoing practice in which progress is continuously examined and the system is adjusted as its environment changes.
Introducing SEDA
The previous sections showed why transformation cannot be understood through technology, process, organization, or culture in isolation. The anti-patterns and guiding principles point toward the same conclusion: meaningful change requires a way to understand the system as a whole and continuously respond to what emerges.
SEDA, the Systemic Event Discovery Approach, was developed for this purpose. It is a cyclic and adaptable approach for exploring and transforming complex software ecosystems through the combined use of Team Topologies1, Domain-Driven Design2, and Systems Thinking3.

Rather than prescribing a fixed sequence toward a predefined end state, SEDA provides a structured way to discover what is happening, understand why it is happening, reshape the system, and continue learning as it evolves. It consists of four iterative steps as follows :
1️⃣ System Discovery and Diagnosis
The first step builds an understanding of the sociotechnical system as it exists today. Systems Thinking helps uncover relationships between visible events and the deeper structures behind them, while Conway’s Law and Brooks’ Law help examine how communication, coordination, and organizational design influence the software ecosystem.
2️⃣ Redesigning Around Domains
The second step moves from understanding the current system to reshaping it around business domains. Domain-Driven Design4 and collaborative techniques such as EventStorming help discover meaningful boundaries, reconsider responsibilities, and align software and team structures more closely with the business.

3️⃣ Managing Emergent Behaviors and Feedback
Redesign changes the system, but it also creates new interactions and dependencies. The third step observes these emerging behaviors and uses feedback to identify growing coordination costs, instability, structural drift, and other consequences that were difficult to anticipate during design.
4️⃣ Sustaining Evolution After Transformation
The fourth step keeps transformation active beyond the initial redesign. Signals, feedback, and continuous learning help organizations recognize when the system begins to drift and determine when parts of SEDA should be applied again. Transformation therefore becomes a continuous cycle rather than a transition toward a fixed end state.
A Continuous Cycle
SEDA is not intended to move transformation through a fixed sequence from beginning to end. What is learned in one step can challenge earlier assumptions, reveal new dependencies, or make it necessary to revisit another part of the system. A signal discovered later may therefore bring attention back to problems that were previously invisible.
This cyclic nature reflects how sociotechnical systems actually evolve. Understanding leads to change, change produces new behavior, and that behavior creates new information. SEDA keeps this learning active, allowing transformation to evolve with the system rather than forcing the system to follow a predefined path.
- Team Topologies — Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow, IT Revolution Press, 2019 — is a practical, step-by-step, adaptive model for organizational design and team interaction based on four fundamental team types and three team interaction patterns. It is a model that treats teams as the fundamental means of delivery, where team structures and communication pathways are able to evolve with technological and organizational maturity. Team Topologies Website ↩︎
- Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. Martin Fowler ↩︎
- Donella H. Meadows, Thinking in Systems: A Primer, Chelsea Green Publishing, 2008 ↩︎
- Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley Professional, 2003 ↩︎




