Redesigning an organization with Cynefin Estuarine mapping and Org Topologies
- Anna Lavrova
- Mar 1
- 12 min read
Context of my engagement as a coach
At the beginning of 2024, the main project of InternetCo was experiencing a convergence of organisational and delivery-related challenges that significantly constrained its effectiveness.
From a delivery perspective, the team struggled with unstable velocity, limited predictability, and recurring misalignment between technical solutions and evolving business requirements. This misalignment was exacerbated by insufficient transparency around timelines and dependencies, making it difficult for both stakeholders and teams to develop a shared understanding of progress and expectations.
At the beginning of my engagement in 2025, I had an assumption that beneath these surface-level symptoms, there were way deeper systemic issues.
More specifically, I hypothesized that the challenges observed were not primarily caused by individual performance or execution discipline, but by an organizational design that constrained how work was defined, how decisions were made, and how skills were allowed to develop. From an organisational topologies perspective, I suspected a misalignment
between the Scope of Work Mandate and the Scope of Skills Mandate, resulting in teams optimising for activity and utilization rather than for end-to-end outcomes and learning. This hypothesis shaped my choice to explore the system before proposing any delivery or framework-level changes.
I observed the following:
Processes were either unclear or inconsistently applied, which led to frequent handoff friction and communication gaps across roles and teams.
Team members reported a diminishing sense of achievement, as work often felt reactive rather than purposeful, and successes were rarely made visible or celebrated. At the same time, opportunities for professional growth and career development were limited, contributing to reduced engagement and long-term motivation.
Compounding these challenges were persistent prioritization problems and an ever-expanding backlog. Work was frequently initiated without sufficient alignment on value or urgency, resulting in context switching and unfinished initiatives.
Technical debt, particularly within operational domains, continued to accumulate further slowing delivery and increasing cognitive load for both development and operations teams.
Together, these factors created reinforcing bottlenecks that affected not only throughput but also morale and trust in the system.
I learned that throughout 2024, these challenges were addressed through a series of deliberate, collaborative interventions aimed at stabilizing the system and creating conditions for sustainable improvement.
The approach I took
A key focus set as my priority was the development and implementation of a clearer, more explicit workflow for the development team.
However, I decided to take a bigger picture approach and see if the elements of the system were aware of the current organization and the results it brings. Introducing or scaling a delivery framework such as Scrum, LeSS, or any other agile method without first understanding the underlying organizational design would have risked local optimization.
Without addressing how work was defined, who had authority to make decisions, and how skills were expected to evolve; any framework adoption would likely reinforce existing constraints rather than resolve them. Therefore, organisational design awareness was treated as a prerequisite for any sustainable delivery improvement, not as a consequence of it.
From a transformational perspective, my work was grounded in a structured approach to data collection and analysis, aimed at understanding how the system actually functioned — not only how it was described—so that leaders could design strategically rather than optimize locally.
The process began with reviewing relevant organizational documents and artifacts. While I am aware that formal documentation rarely reflects lived reality, in this case, it served two important purposes. First, InternetCo historically took pride in its extensive documentation practices and standard operating procedures; reviewing these artefacts was therefore a way to acknowledge the organization's identity and respect its historical investments. Second, documents provided insight into the declared governance model: how authority, responsibilities, and workflows were formally designed.
These artifacts were treated not as reliable representations of behavior, but as expressions of intent and structural assumptions. The gaps between documented processes and actual practice later became diagnostically useful.
This document review was followed by structured interviews and surveys with executives, employees, and cross-functional teams, allowing multiple lived perspectives on the system to emerge and enabling comparison between formal design and operational reality.
In the surveys and interviews, my key questions were aimed at:
1) Understanding the need behind optimization (basically, what are we optimizing for, but not asked bluntly). Examples of questions were:
What gets celebrated, promoted, or rewarded?
When trade-offs arise, what usually wins: speed, utilization, predictability, or impact?
Where do we still deliver activity instead of customer-relevant outcomes?
Which work feels “done” but creates little real value to users or to the business?
2) Understanding the Scope of Work Mandate:
Who decides what work gets done? And what source of inflow to backlog exists?
What problems are teams not allowed to solve?
Where do handoffs occur because “this is not our responsibility”?
What work requires coordination across many units to complete?
3) Understanding the Scope of Skills Mandate:
What skills are people expected to develop over time?
Where do specialists wait for other specialists to act?
How easy is it to learn adjacent skills while doing real work?
Workshops part 1
The primary intention of the workshop series was not to design a future organization immediately but to create a shared understanding of the current one. By involving cross-team representatives in mapping the system, the goal was to enable collective sense-making, surface implicit assumptions, and ensure that any transformation backlog would be perceived as emerging from the system itself rather than being imposed externally.
The first workshop was adapted from the Estuarine Mapping tool from Cynefin to see the system they operate in and visualize the organizational landscape. (Practically this is Butterfly Stamping, a prelude to Estuarine Mapping) with attributes and objects from the organization.
Pictures A and B show the current state.
Pictures C and D show the desired state.
The middle zone of Estuarine Mapping has been selected as things that can be changed and are worth changing.
The Estuarine Mapping workshop revealed structural tensions between declared intent and enacted behavior. Participants identified multiple forces shaping the current state: strong functional identity, historical investment in specialization, centralized prioritization, and implicit incentives favoring utilization over end-to-end ownership.
I observed several key results:
1. Many elements placed in the “stable” zone were functional departments and expertise pools, indicating structural inertia around skill-based grouping.
2. Units positioned in the “changeable” middle zone often related to coordination mechanisms (backlog structure, ownership clarity, sequencing practices), suggesting that the organization experienced friction primarily at interfaces rather than within functions.
3. Desired-state mapping consistently moved elements toward clearer product-level ownership and reduced cross-functional dependencies, signaling collective recognition that mandate fragmentation and not lack of competence was constraining flow.
Workshops part 2
The second part of the workshop was dedicated to mapping the current organizational design. I used a two-phase approach. In the first phase of the workshop, the intention was to examine how the organization distributed and exercised the four core organizational functions described in Org Topologies: Directing, Doing, Delivering, and Driving.
Rather than treating these as abstract categories, we used them as diagnostic lenses to understand how mandate and authority were actually distributed.
Delivering Intelligence
Where is the flow smooth, and where does work pile up?
What slows work down more: lack of skill or lack of coordination?
Driving Intelligence
Who understands customer impact end-to-end?
Where are product decisions disconnected from delivery reality?
Directing Intelligence
Who can explain why this org is designed this way?
How often is strategy revisited based on learning, not planning?
Adaptive Intelligence
How easy is it to change direction once work is underway?
These conversations allowed participants to observe whether the organisation behaved closer to a Resource topology (strong Doing, centralised Directing), a Delivery topology (stable Delivering units), or an Adaptive topology (distributed Directing and expanded Scope of Work Mandate).
Do people primarily move between initiatives, or does work move to stable groups?
Are teams formed around skills, around delivery goals, or around evolving problem
spaces?
Where does coordination happen: managers, meetings, or shared artifacts?
In the next stage of the workshop (afternoon), we were focused on mapping the current state of affairs, following the principle of Complete/Incomplete and Output/Outcome focused.
Study boundary: whole organization
Note: I also used this visualization to explain the why behind mapping the current design before starting any transformation; hence, both OrgTopologies and my approach were framework-agnostic, but focused on the design and how people interact.
The collected data were then synthesised to identify recurring patterns, systemic tensions, and opportunities for improvement.
The conclusion, as referenced in the Primer, suggests that:
“Grouping individuals into functional units results in a more reliable system of staged development across functional silos. In this paradigm, we group the individuals of a similar skill, creating functional departments or functional groups. Although we didn’t break the functional silos yet, these departments are better at balancing workload than single individuals. Here, the hand-offs and information scatter create an increased coordination need, resulting in a slow product development system.”
The organization predominantly operated in a Resource topology. Individuals and teams were grouped by function and specialization, and work flowed across those units through sequential handoffs. Scope of Skills Mandate was deep but narrow: specialists optimized within their domain (e.g., backend, operations, infrastructure), with limited horizontal capability overlap. Scope of Work Mandate remained constrained to partial solutions; most units delivered components, services, or expertise rather than complete, customer-relevant outcomes.
Directing authority was centralized, with prioritization and sequencing decisions occurring outside of delivery units. Delivering relied heavily on cross-functional coordination rather than stable end-to-end accountability. As a result, flow depended on negotiation between functions, and ownership of outcomes was diluted across multiple roles. Coordination cost, dependency management, and escalation patterns were structural features rather than exceptions.
These characteristics align with Resource topology patterns described in the Org Topologies Primer: optimization around resource utilization, functional workload balancing, and governance-driven sequencing, rather than outcome-centered, stable delivery units.
The desired state of transformation looked like this:
A potential early result, as stated in the Primer, would be:
“In comparison to managing tasks, working with features at the second level makes managing product development easier. Each work unit at this level is likely to have an independent set of goals, a roadmap, and a backlog at the feature level. This setup creates clear responsibility for whose those features are.”
Next steps and transformation backlog
Combined results have been digested into a set of recommendations and short-term and long-term goals, together with the implementation of Elevating Katas.
Some recommendations included:
Improve the vision and goals with
1) Creation and communication of annual objectives and/or quarterly key results with
Vision and Roadmap
2) Map out dependencies and allocate resources
Quarterly planning together
Insights and transparency on status
3) Use prioritisation techniques
4) Introduce the feature owner as a role responsible for why-what-how alignment.
5) Set up a Kanban board to visualize work and encourage collaboration for all teams.
6) Establish stand-up meetings to increase alignment and help address bottlenecks.
7) Integrate retrospectives to encourage a culture of continuous improvement and develop innovative solutions.
8) Choose and implement agile delivery workflow (scrum, scrum at scale, less, etc.)
9) Set up knowledge sharing and technical COPs so that leaders are not centralizing knowledge and creating a bus factor.
Short-term goals:
Reorganize the operations team into a Kanban workflow
Clarify roles and responsibilities
Establish a regular feedback loop
Set up refinement practices and coach the team in agile principles
Develop a prioritization and estimation method
Set up and configure task tracking and planning tools
Long-term strategies:
Formalize an approach to project management and document key processes
Implement a quarterly planning cycle (set OKRs).
Regularly review and prioritize the project backlog
Break the organizational silos through team coaching
Reach effective collaboration through team and leadership coaching
Create end-to-end fast flow teams
Ensure the whole organization's business focus
According to the Primer, Elevating Katas exist to systematically push the organization toward the upper-right of the Org Topologies map, higher Scope of Work Mandate, and Scope of Skills Mandate without breaking the system.
Each kata targets one or more org design elements simultaneously:
Structure (how work is grouped)
Governance (who decides what)
Roles (what authority people really have)
Events (how coordination happens)Artifacts (what makes work visible)
The selected Elevating Katas were chosen to incrementally expand both the Scope of Work Mandate and the Scope of Skills Mandate without destabilising the system. For example, elevating Product Ownership and introducing feature-level responsibility, targeted governance, and role clarity, enabling clearer alignment between why, what, and how.
Merging product backlogs and establishing multi-team backlog refinement addressed structural fragmentation and reduced coordination overhead. Introducing shared definitions of “Done” and visual flow artefacts increased transparency and supported outcome-oriented conversations.
Each kata was designed as a learning mechanism rather than a fixed solution, allowing the organisation to adapt based on feedback rather than enforcing a predefined end state.
The timeline for short-term goals has been selected as Q1 2026 and long-term as Q4 2026.
Some short-term results as of Jan 5, 2026:
Stable agile cadence embedded across teams (scrum for dev teams and reorganized operations team into Kanban workflow)
Business–IT dialogue significantly improved
Delivery transparency on incidents and releases increased
Openness to training and structured learning strengthened
Clarified roles and responsibilities
Established a regular feedback loop
Elevated Product Ownership and trained POs
Set up refinement practices and coach the team in agile principles
Developed a prioritization and estimation method
Set up and configure task tracking and planning tools
Started holding Multi-Team Product Backlog Refinement (PBR)
Merged Product Backlogs for 3 directions
Defined shared “Done.
These outcomes indicate that team-level agility was successfully established and is no longer theoretical. However, as predicted by Org Topologies, improvements in rituals surfaced deeper systemic constraints.
Five systemic challenges became clearer:
Fragmented end-to-end ownership (handoffs still slow flow)
Weak systemic follow-through (structural problems reappear)
Vision insufficiently translated into daily work
Underinvestment in technical foundations (CI/CD, infrastructure)
Incentives misaligned with outcome ownership and growth
These tensions are consistent with an organization transitioning from Resource toward Delivery topology: improved Doing and Delivering expose constraints in Directing and Driving.
Importantly, the visibility of these constraints was interpreted as progress rather than failure. In a Resource topology, structural issues remain obscured by functional buffering. In transition, they become explicit and therefore actionable.
The next phase of transformation was designed as a deliberate shift from team-level agility toward organizational agility, meaning expansion of mandate, structural alignment, and governance clarity.
Rather than introducing additional rituals, the focus of 2026 was structured around three evolutionary horizons:
Horizon 1 (Months 0–3)
Actions together with Elevating Katas in this horizon target structural bottlenecks:
Establish a weekly organizational impediment forum to surface cross-team constraints so that it is possible make structural blockers visible and assign executive ownership
Create a temporary DevOps enablement squad to unblock flow
Elevate CI/CD stabilization to a top organizational priority
Support cross-team alignment without hierarchy (and Lead with OBEYA strategically).
Horizon 2 (Months 4–6)
Define and publish initiative charters with explicit product outcome ownership
Ensure strategic alignment and adaptability (and Expand the “Product” Definition)
Clarify WHAT (business intent) versus HOW (implementation decisions)
Expand Scope of Work Mandate from task execution to feature-level accountability
Horizon 3 (Months 7–12): Institutionalize Capability and Ownership
The final horizon focuses on embedding sustainability rather than introducing new mechanics.
Key Actions:
Launch Communities of Practice to expand horizontal skill mandate
Introduce Individual Development Plans aligned with evolving topology
Integrate HR into transformation governance
Protect 5% innovation capacity to enable adaptive experimentation
Conclusion
By deliberately slowing down at the beginning of the engagement and focusing on understanding how the organization actually functioned, rather than how it was described, I was able to surface the implicit rules, incentives, and constraints that governed behavior. I am glad I got to combine OrgTopologies with Cynefin tools so I could reach more participants and get multi-dimensional perspectives.
The combination of document review, interviews, surveys, and participatory workshops created a shared mirror for the organization, allowing leaders and teams to see not only what was happening but also why the system was producing the results it was producing. This shared understanding proved to be a critical prerequisite for change.
More precisely, the organization operated predominantly in a functional (resource-oriented) topology, characterized by a limited Scope of Work Mandate and a specialized, function-bound Scope of Skills Mandate. Individuals and teams were grouped primarily by skill and function, while work flowed across those units through handoffs and coordination mechanisms. While this topology provided a sense of workload balancing and role clarity, it also increased coordination cost, slowed feedback loops, and diluted ownership of customer-relevant outcomes.
Scope of Work Mandate was limited to partial solutions; most units contributed components rather than complete customer-relevant outcomes. The intended shift toward a Delivery topology did not imply abandoning functional expertise, but reorganizing work around stable, end-to-end accountable units. In a Delivery topology, Scope of Work Mandate expands from partial contribution to complete solution ownership, while Scope of Skills Mandate expands horizontally — enabling multi-skilled collaboration within stable groups.
Importantly, the organization did not need a radical or disruptive redesign (their initial scope was only focused on the delivery framework, and they would be satisfied with “just” setting up scrum teams); instead, it needed a series of intentional, safe-to-try shifts that would gradually redesign the organization while not being tied by any framework they thought they needed at the moment. The selected recommendations and Elevating Katas were therefore not treated as a transformation “plan,” but as mechanisms for learning.
The early results achieved by January 2026 demonstrate that meaningful progress can be made without destabilizing the system, provided that organizational change is grounded in transparency, participation, and respect for existing constraints.
Beyond the visible structural changes, the most significant outcome of this engagement was a shift in how the organization reasons about problems. Leaders and teams began to distinguish between delivery issues and design constraints and to approach improvement as an ongoing learning process rather than a one-time reorganization. For me as a coach, this case reinforced the value of organizational topologies not as a prescriptive framework, but as a sense-making discipline that enables deliberate, context-sensitive change. Rather than asking “Which framework should we implement?”, the organization learned to ask, “What kind of system do we need to become to achieve the outcomes we care about?”