Analyzing dependencies

Why analyzing dependencies matters

Dependencies between capabilities can significantly impact how effectively value flows through your organization. By visualizing these dependencies, you can identify bottlenecks, uncover risks, and assess how teams are spread across multiple contexts. This process helps highlight excessive cognitive load, context switching, and areas where team focus may be diluted.

Key actions

  1. Overlay existing teams: Use sticky notes to map current team structures onto the User Needs Map. Identify areas where teams are stretched across multiple dependencies.
  2. Assess cognitive load: Examine how much context switching teams must do, particularly in cases like front-end/back-end team splits.
  3. Identify bottlenecks and awkward interactions: Highlight areas where dependencies create inefficiencies, delays, or excessive handoffs.
  4. Spot opportunities for change: Determine where dependencies could be reduced or where collaboration should be better structured to improve delivery.

Evaluating team spread and cognitive load

Overlaying existing teams on the dependency map helps expose:

  • Teams spread too thin across multiple, disconnected capabilities.
  • High cognitive load due to excessive context switching between unrelated domains.
  • Unclear ownership of key capabilities.

For example, at Passenger, at the time there was only an Engineering Team that was responsible for the entire passenger ecosystem. The team was stretched across multiple capabilities, leading to high cognitive load and delays. During daily standups, different team members were reporting on different capabilities, leading to a lack of clarity and ownership. The team had multiple stakeholders, with members of the team being pulled in different directions and they were struggling to prioritize their work.

Being able to visualize how the current team structures are assigned to each of the capabilities helps expose the reality of the situation. Measuring cognitive load is not an exact science but can often be inferred when you see the huge variety of domain knowledge required for the team to understand each of the capabilities they are responsible for.

Exploring overlapping dependencies

After mapping the dependencies between capabilities, the next step is to explore any obvious situations where the dependency lines cross over each other. This is a great opportunity to identify awkward interactions and areas where dependencies might be creating inefficiencies, delays, or excessive handoffs but also opportunities to seek ways to break up monolithic parts of the system.

Removing Overlapping dependencies

We might choose to explore what fracture planes (ways to break up the monolith) might be useful in each situation - during discussions make notes of these potential options.

Tools and techniques

  • Sticky notes & whiteboards: Use physical tools in a workshop setting to visualize dependencies.
  • Color coding: Use different coloured stickies to highlight where teams or tech systems are involved in the map.
  • Miro or Lucidchart: For remote teams, collaborative tools can replicate this process.

Exercise: Identify key dependency issues

Using your User Needs Map, analyze the dependencies and team ownership:

  1. Overlay your teams onto the map. Are teams stretched across too many areas?
  2. Mark cognitive load risks. Where do teams need to switch contexts frequently?
  3. Identify dependency bottlenecks. Are any teams or capabilities becoming delivery blockers?
  4. Discuss opportunities for improvement. Where could dependencies be reduced or ownership restructured?

What’s Next?

Now that you’ve visualized dependencies and assessed team spread, the next step is to define better team boundaries that align with capabilities while minimizing cognitive load and coordination overhead.
Proceed to Step 6: Defining Team Boundaries

Need help to get things moving?

If you are looking for help to get started, please do not hesitate to reach out.

Reach out to us