---
title: "Reducing dependencies"
description: "At a certain size, organizational dependencies will kill you. Here's a menu of options to fix it."
url: "https://www.rubick.com/reducing-dependencies/"
---

# Reducing dependencies

September 13, 2025 by Jade Rubick

[#delivery](https://www.rubick.com/tags/delivery/) [#complexity](https://www.rubick.com/tags/complexity/) [#scaling](https://www.rubick.com/tags/scaling/) [#org-design](https://www.rubick.com/tags/org-design/)

When your company gets large enough, you’ll start having problems with dependencies. Here’s how to address it.

![Deps](https://www.rubick.com/_astro/deps.-6NEJBy5_Z2gV6a5.webp)

## What do I mean by dependencies?

-   Teams not able to deliver their work without other teams doing work for them.
-   Projects that can’t be successful unless a lot of teams do work.

## Signs you have a problem

-   Big projects are always challenging and problematic.
-   Lots of efforts to solve this through project management and better tracking.
-   Lots of efforts to solve this through heroism.
-   Lots of efforts to solve this through process.

The problem is that you have a structural problem, so none of these will work consistently. I write more about how people [try to work around these structural problems](https://www.rubick.com/independent-executor-model/).

## All the things you can do

-   **Reorganize the teams** to reduce dependencies. Generally favor cross-functional organization. [Team Topology](https://www.rubick.com/management-books/) style structures. Or [FaST](https://www.rubick.com/fast-agile/) approaches if you have a higher tolerance for experimental but promising approaches. There is a lot of nuance in this — it’s a fairly advanced leadership topic. You might have different models in different parts of your org, for example.
-   **Make your projects smaller and more incremental**. It’s easier to ship smaller things.
-   **Focus on fewer things**. If you halve the number of projects, that means each projects gets that much more attention, project management, attention to detail, etc. If a manager is project managing four things, they’re dramatically less effective that project managing one thing. Consider constraints on the number of projects per team.
-   **Define engagement models for your teams**. I write about a lot of these in [Coordination models](https://www.rubick.com/coordination-models/). Be very explicit about the way teams work with each other. You might have a team page in the wiki, with a section on the engagement model for each team. Examples of engagement models: [self-service](https://www.rubick.com/platform-teams-and-the-self-service-model/), [independent executor](https://www.rubick.com/independent-executor-model/), [objective expert](https://www.rubick.com/objective-expert-model/). Moving all your platform teams to self-service is an example of a very good improvement.
-   **Define how to work across team boundaries**. Away teams, open source model, etc. I haven’t completed some of those posts yet, but have some detail in the [independent executor](https://www.rubick.com/independent-executor-model/) post.
-   **Look at your bottlenecks**. You always will have [bottleneck teams](https://www.rubick.com/bottleneck-team/). Not only are these usually the most problematic places in engineering, they also are often where a fix can have outsized impact throughout the whole organization.
-   **Have someone who explicitly looks at dependencies and org structure**. If you don’t have enough systems thinkers in the organization, it might be useful to make this more explicitly something that the right person is thinking about a lot. Dependencies are one of the main decelerants for your org — make someone responsible for taking care of the org structure.
-   **Bring in consultants or advisors**. This can go very well, or very poorly. But it can be a good idea to bring in outside expertise. Be wary of [SAFe](https://www.rubick.com/wiki/process/safe/) or other one size fits all approaches. I can help, or refer you to others.

## Thank you

Image by [Trond Giæver Myhre](https://pixabay.com/users/trondmyhre4-5401410/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=6579313) from [Pixabay](https://pixabay.com//?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=6579313)

I like to share what I’ve learned. If you’re running into something like this at your company, [I’m happy to talk](https://www.rubick.com/work-with-me/).